From mpetach at netflight.com Wed Oct 1 03:17:19 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 30 Sep 2014 20:17:19 -0700 Subject: GMail contact - misroute / security issue In-Reply-To: References: <5428D540.7080904@tnetconsulting.net> Message-ID: On Sun, Sep 28, 2014 at 8:52 PM, James Welcher wrote: > Gmail will strip out periods. > OMG, I am *so* telling my GF about that feature! Matt From RCzumbil at xand.com Wed Oct 1 05:28:12 2014 From: RCzumbil at xand.com (Romeo Czumbil) Date: Wed, 1 Oct 2014 05:28:12 +0000 Subject: Verizon FiOS IPv6 Message-ID: Does anybody have any idea on when Verizon FiOS is turning up IPv6? (dual-stack) Thank you in advance From morrowc.lists at gmail.com Wed Oct 1 05:35:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 1 Oct 2014 01:35:15 -0400 Subject: Verizon FiOS IPv6 In-Reply-To: References: Message-ID: On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil wrote: > Does anybody have any idea on when Verizon FiOS is turning up IPv6? (dual-stack) looking at the archives is helpful in this question/answer process.. but to save you the digging: "When there's ice in the devil's house" (essentially) From seitz at bsd-unix.net Wed Oct 1 05:44:19 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Wed, 1 Oct 2014 01:44:19 -0400 Subject: Verizon FiOS IPv6 In-Reply-To: References: Message-ID: <20141001054419.GA16195@bsd-unix.net> On Wed, Oct 01, 2014 at 01:35:15AM -0400, Christopher Morrow wrote: > On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil wrote: > > Does anybody have any idea on when Verizon FiOS is turning up IPv6? (dual-stack) > > looking at the archives is helpful in this question/answer process.. > but to save you the digging: "When there's ice in the devil's house" > (essentially) Yeah... although they seem to be releasing a new residential gateway that does IPV6 as well as 802.11AC. Maybe this is a good sign ? :) http://www.dslreports.com/shownews/Verizon-Preps-Launch-of-New-FiOS-Gateway-130273 -- Bryan G. Seitz From anthonyrjunk at gmail.com Wed Oct 1 14:32:17 2014 From: anthonyrjunk at gmail.com (Anthony Junk) Date: Wed, 1 Oct 2014 10:32:17 -0400 Subject: Verizon FiOS IPv6 In-Reply-To: <20141001054419.GA16195@bsd-unix.net> References: <20141001054419.GA16195@bsd-unix.net> Message-ID: I already have IPv6 on my router at home. They rolled out an update a few months back that added the capability for the latest 802.1N model. I'm not at home to look at it but I'll update with the model this evening. Sincerely, Anthony R Junk Network and Security Engineer (410) 929-1838 anthonyrjunk at gmail.com On Wed, Oct 1, 2014 at 1:44 AM, Bryan Seitz wrote: > On Wed, Oct 01, 2014 at 01:35:15AM -0400, Christopher Morrow wrote: > > On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil wrote: > > > Does anybody have any idea on when Verizon FiOS is turning up IPv6? > (dual-stack) > > > > looking at the archives is helpful in this question/answer process.. > > but to save you the digging: "When there's ice in the devil's house" > > (essentially) > > Yeah... although they seem to be releasing a new residential gateway that > does IPV6 as > well as 802.11AC. Maybe this is a good sign ? :) > > > http://www.dslreports.com/shownews/Verizon-Preps-Launch-of-New-FiOS-Gateway-130273 > > -- > > Bryan G. Seitz > From jra at baylink.com Wed Oct 1 14:39:11 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 01 Oct 2014 10:39:11 -0400 Subject: .sj/.bv == privacy? Message-ID: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> Here's an interesting, and fairly thoughtful and well written, piece about talks going on in Norway to utilize two ccTLDs which are assigned to the country for outlying territories for the purpose of a specialty domain registry where registrants (such as hosting companies) would be contractually required to guarantee privacy to their end customers. I think the idea has some merit, myself; I have always preferred to see municipalities, frex, registered in domains where it's clear they had to /be the municipality/ to get the registration... to avoid things like the Largo.com Joe job of earlier years. (Yay, RFC1480!) But I'm not sure if a ccTLD is the place to put that. I'm sure the argument is "well this puts the weight of the country of Norway behind it". But that's a sword that cuts both ways. http://www.zdnet.com/how-two-remote-arctic-territories-became-the-front-line-in-the-battle-for-internet-privacy-7000034245/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From streiner at cluebyfour.org Wed Oct 1 14:57:39 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 1 Oct 2014 10:57:39 -0400 (EDT) Subject: Verizon FiOS IPv6 In-Reply-To: References: <20141001054419.GA16195@bsd-unix.net> Message-ID: On Wed, 1 Oct 2014, Anthony Junk wrote: > I already have IPv6 on my router at home. They rolled out an update a few > months back that added the capability for the latest 802.1N model. I'm not > at home to look at it but I'll update with the model this evening. Like many others, I would be interested to hear more about this. Verizon pushed a firmware update to my Fios router some time ago that supports IPv6, but I was not receiving native v6 connectivity from Verizon at home. I think they did some small-scale deployments as a test, and maybe you're in one of the areas they rolled out, but I don't think there are any larger deployments on the immediate radar. My calls to the front-line call center (I make a point of doing this every few months) generally get no information. Offering to put a note in my account stating that I asked about IPv6 is only useful if someone from Verizon actually goes back and reads those notes. Shaking other trees at Verizon through $dayjob has not produced any better results so far. Until Verizon offers native IPv6, I will continue using my tunnel through HE, which has been rock-solid. jms > On Wed, Oct 1, 2014 at 1:44 AM, Bryan Seitz wrote: > >> On Wed, Oct 01, 2014 at 01:35:15AM -0400, Christopher Morrow wrote: >>> On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil wrote: >>>> Does anybody have any idea on when Verizon FiOS is turning up IPv6? >> (dual-stack) >>> >>> looking at the archives is helpful in this question/answer process.. >>> but to save you the digging: "When there's ice in the devil's house" >>> (essentially) >> >> Yeah... although they seem to be releasing a new residential gateway that >> does IPV6 as >> well as 802.11AC. Maybe this is a good sign ? :) >> >> >> http://www.dslreports.com/shownews/Verizon-Preps-Launch-of-New-FiOS-Gateway-130273 >> >> -- >> >> Bryan G. Seitz >> > From dhubbard at dino.hostasaurus.com Wed Oct 1 15:23:09 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 1 Oct 2014 11:23:09 -0400 Subject: Verizon FiOS IPv6 References: <20141001054419.GA16195@bsd-unix.net> Message-ID: The actiontec I have from them, for years now, supports IPv6, they just don't support it at the ONT or further upstream; no idea where the limitation is. I don't use their router though, just get ethernet from the ONT. We have Fios in a few remote offices; hitting them up from the business side didn't make a difference either. They just suck and I don't anticipate that changing. You'd think they could hire some of the folks from the cellular side to come fix the Fios network. IPv6 works great on the LTE net. David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin M. Streiner Sent: Wednesday, October 01, 2014 10:58 AM To: NANOG Subject: Re: Verizon FiOS IPv6 On Wed, 1 Oct 2014, Anthony Junk wrote: > I already have IPv6 on my router at home. They rolled out an update a > few months back that added the capability for the latest 802.1N model. > I'm not at home to look at it but I'll update with the model this evening. Like many others, I would be interested to hear more about this. Verizon pushed a firmware update to my Fios router some time ago that supports IPv6, but I was not receiving native v6 connectivity from Verizon at home. I think they did some small-scale deployments as a test, and maybe you're in one of the areas they rolled out, but I don't think there are any larger deployments on the immediate radar. My calls to the front-line call center (I make a point of doing this every few months) generally get no information. Offering to put a note in my account stating that I asked about IPv6 is only useful if someone from Verizon actually goes back and reads those notes. Shaking other trees at Verizon through $dayjob has not produced any better results so far. Until Verizon offers native IPv6, I will continue using my tunnel through HE, which has been rock-solid. jms > On Wed, Oct 1, 2014 at 1:44 AM, Bryan Seitz wrote: > >> On Wed, Oct 01, 2014 at 01:35:15AM -0400, Christopher Morrow wrote: >>> On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil wrote: >>>> Does anybody have any idea on when Verizon FiOS is turning up IPv6? >> (dual-stack) >>> >>> looking at the archives is helpful in this question/answer process.. >>> but to save you the digging: "When there's ice in the devil's house" >>> (essentially) >> >> Yeah... although they seem to be releasing a new residential gateway >> that does IPV6 as well as 802.11AC. Maybe this is a good sign ? :) >> >> >> http://www.dslreports.com/shownews/Verizon-Preps-Launch-of-New-FiOS-G >> ateway-130273 >> >> -- >> >> Bryan G. Seitz >> > From mehmet at akcin.net Wed Oct 1 15:35:53 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 1 Oct 2014 08:35:53 -0700 Subject: .sj/.bv == privacy? In-Reply-To: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> References: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> Message-ID: I am not opposed to the proposed use but that doesn't seem to be a great fit for what I believe a practice for a ccTLD should be. mehmet On Wed, Oct 1, 2014 at 7:39 AM, Jay Ashworth wrote: > Here's an interesting, and fairly thoughtful and well written, piece about > talks going on in Norway to utilize two ccTLDs which are assigned to the > country for outlying territories for the purpose of a specialty domain > registry where registrants (such as hosting companies) would be > contractually required to guarantee privacy to their end customers. > > I think the idea has some merit, myself; I have always preferred to see > municipalities, frex, registered in domains where it's clear they had to > /be the municipality/ to get the registration... to avoid things like the > Largo.com Joe job of earlier years. (Yay, RFC1480!) > > But I'm not sure if a ccTLD is the place to put that. I'm sure the > argument is "well this puts the weight of the country of Norway behind it". > But that's a sword that cuts both ways. > > > http://www.zdnet.com/how-two-remote-arctic-territories-became-the-front-line-in-the-battle-for-internet-privacy-7000034245/ > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From brfree at adobe.com Wed Oct 1 16:07:12 2014 From: brfree at adobe.com (Brian Free) Date: Wed, 1 Oct 2014 16:07:12 +0000 Subject: MetroE Providers Message-ID: <27e5f7e1ad614bfd8fcf3abeae4feb5e@BLUPR02MB343.namprd02.prod.outlook.com> Brent, It's been awhile since I used it seriously, but dslreports.com comes to mind. Cheers, Brian -----Original Message----- Date: Tue, 30 Sep 2014 21:42:53 +0000 From: "Meshier, Brent" To: "nanog at nanog.org" Subject: MetroE Providers Message-ID: <68C2CBC977F3E04799DF9C76E938E7090859F94D at DFEXCH1.asglp.com> Content-Type: text/plain; charset="us-ascii" Are there any sites or services that can list local network providers by zip code or address? We're constantly opening up regional offices across the US and need to streamline the process of obtaining connectivity. --Brent --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From dhc2 at dcrocker.net Wed Oct 1 16:08:19 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 01 Oct 2014 09:08:19 -0700 Subject: .sj/.bv == privacy? In-Reply-To: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> References: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> Message-ID: <542C26F3.6000107@dcrocker.net> > for the purpose of a specialty domain registry where registrants (such as hosting companies) would be contractually required to guarantee privacy to their end customers. Hmmm... Until privacy is a feature across many/most hosting services, anyone specializing it is, in effect, identifying traffic that is likely to be /more/ interesting for those wishing to inspect the data. In other words, anything that explicitly identifies traffic as attempting greater privacy is likely to be a greater target for attack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rwebb at ropeguru.com Wed Oct 1 16:43:14 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 01 Oct 2014 12:43:14 -0400 Subject: MetroE Providers In-Reply-To: <27e5f7e1ad614bfd8fcf3abeae4feb5e@BLUPR02MB343.namprd02.prod.outlook.com> References: <27e5f7e1ad614bfd8fcf3abeae4feb5e@BLUPR02MB343.namprd02.prod.outlook.com> Message-ID: I am on DSLreports quite often and do not believe their database is updated much anymore. Was great back in the DSL days though. Although this one forum might be ok for asking: http://www.dslreports.com/forum/isp2isp On Wed, 1 Oct 2014 16:07:12 +0000 Brian Free wrote: > Brent, > It's been awhile since I used it seriously, but dslreports.com comes >to mind. > > Cheers, > Brian > > -----Original Message----- > Date: Tue, 30 Sep 2014 21:42:53 +0000 >From: "Meshier, Brent" > To: "nanog at nanog.org" > Subject: MetroE Providers > Message-ID: > <68C2CBC977F3E04799DF9C76E938E7090859F94D at DFEXCH1.asglp.com> > Content-Type: text/plain; charset="us-ascii" > > Are there any sites or services that can list local network >providers by zip code or address? We're constantly opening up >regional offices across the US and need to streamline the process of >obtaining connectivity. > > --Brent > --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ >for important disclosures regarding this electronic communication. > > From Valdis.Kletnieks at vt.edu Wed Oct 1 16:43:56 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Oct 2014 12:43:56 -0400 Subject: .sj/.bv == privacy? In-Reply-To: Your message of "Wed, 01 Oct 2014 09:08:19 -0700." <542C26F3.6000107@dcrocker.net> References: <10946629-4d0d-4f41-8110-bedc41509b3a@email.android.com> <542C26F3.6000107@dcrocker.net> Message-ID: <5671.1412181836@turing-police.cc.vt.edu> On Wed, 01 Oct 2014 09:08:19 -0700, Dave Crocker said: > In other words, anything that explicitly identifies traffic as > attempting greater privacy is likely to be a greater target for attack. Which is a good reason to encrypt all network traffic by default, even if it's just videos of kittens. You can still figure out a lot by doing endpoint analysis, but it's a start (especially if one endpoint is an 800 pound gorilla that can serve up almost anything). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From shortdudey123 at gmail.com Wed Oct 1 18:01:37 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 1 Oct 2014 11:01:37 -0700 Subject: AWS EC2 us-west-2 reboot In-Reply-To: <20140924204138.5a6bdf1d.reed@reedloden.com> References: <20140924204138.5a6bdf1d.reed@reedloden.com> Message-ID: For those interested, this is the Xen bug they were fixing with the reboots http://xenbits.xen.org/xsa/advisory-108.html -Grant On Wed, Sep 24, 2014 at 8:41 PM, Reed Loden wrote: > On Wed, 24 Sep 2014 21:39:39 -0400 > Peter Beckman wrote: > > > Likely some sort of potentially serious bug or flaw in EC2 or Xen. AWS > > Security is really on the ball on such things and do everything they can > to > > make invisible fixes with no customer impact, but sometimes a reboot is > > required in order to apply the changes necessary to keep customer > instances > > safe from attacks and vulnerabilities. > > Rumor mill is that it's XSA-108, embargoed until 2014-10-01 12:00 > (http://xenbits.xen.org/xsa/). Just somebody's guess, though, afaik. > > ~reed > From mpalmer at hezmatt.org Wed Oct 1 20:29:09 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 2 Oct 2014 06:29:09 +1000 Subject: AWS EC2 us-west-2 reboot In-Reply-To: References: <20140924204138.5a6bdf1d.reed@reedloden.com> Message-ID: <20141001202909.GG16215@hezmatt.org> On Wed, Oct 01, 2014 at 11:01:37AM -0700, Grant Ridder wrote: > For those interested, this is the Xen bug they were fixing with the reboots > http://xenbits.xen.org/xsa/advisory-108.html Ouch. Good thing Bashpocalypse is still capturing everyone's attention... Interestingly, Amazon *didn't* discover this bug, which makes one wonder why they, out of all the big Xen-based providers out there, got a heads-up in advance of the embargo end. If I was a big provider who didn't get advance notice, I'd be somewhat miffed. - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From fehwalker at gmail.com Wed Oct 1 20:38:38 2014 From: fehwalker at gmail.com (Bryan Fullerton) Date: Wed, 01 Oct 2014 16:38:38 -0400 Subject: AWS EC2 us-west-2 reboot In-Reply-To: <20141001202909.GG16215@hezmatt.org> References: <20140924204138.5a6bdf1d.reed@reedloden.com> <20141001202909.GG16215@hezmatt.org> Message-ID: <542C664E.7010209@gmail.com> On 01/10/2014 4:29 PM, Matt Palmer wrote: > On Wed, Oct 01, 2014 at 11:01:37AM -0700, Grant Ridder wrote: >> For those interested, this is the Xen bug they were fixing with the reboots >> http://xenbits.xen.org/xsa/advisory-108.html > Ouch. Good thing Bashpocalypse is still capturing everyone's attention... > > Interestingly, Amazon *didn't* discover this bug, which makes one wonder why > they, out of all the big Xen-based providers out there, got a heads-up in > advance of the embargo end. If I was a big provider who didn't get advance > notice, I'd be somewhat miffed. Rackspace did reboots over the weekend for this as well - http://www.rackspace.com/blog/an-apology/ Bryan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From toddunder at gmail.com Wed Oct 1 20:59:42 2014 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 1 Oct 2014 16:59:42 -0400 Subject: AWS EC2 us-west-2 reboot In-Reply-To: <542C664E.7010209@gmail.com> References: <20140924204138.5a6bdf1d.reed@reedloden.com> <20141001202909.GG16215@hezmatt.org> <542C664E.7010209@gmail.com> Message-ID: read: http://www.xenproject.org/security-policy.html they have a sensible, commonly used security policy that involves private notification to large customers in advance where it is practical and there is not evidence of ongoing exploits in the wild. this is kind of incident handling 101 and shouldn't be surprising to anyone. t On Wed, Oct 1, 2014 at 4:38 PM, Bryan Fullerton wrote: > > On 01/10/2014 4:29 PM, Matt Palmer wrote: > >> On Wed, Oct 01, 2014 at 11:01:37AM -0700, Grant Ridder wrote: >> >>> For those interested, this is the Xen bug they were fixing with the >>> reboots >>> http://xenbits.xen.org/xsa/advisory-108.html >>> >> Ouch. Good thing Bashpocalypse is still capturing everyone's attention... >> >> Interestingly, Amazon *didn't* discover this bug, which makes one wonder >> why >> they, out of all the big Xen-based providers out there, got a heads-up in >> advance of the embargo end. If I was a big provider who didn't get >> advance >> notice, I'd be somewhat miffed. >> > > Rackspace did reboots over the weekend for this as well - > http://www.rackspace.com/blog/an-apology/ > > Bryan > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > From nanog at techmonkeys.org Wed Oct 1 21:16:04 2014 From: nanog at techmonkeys.org (Jeff Fisher) Date: Wed, 01 Oct 2014 15:16:04 -0600 Subject: AWS EC2 us-west-2 reboot In-Reply-To: References: <20140924204138.5a6bdf1d.reed@reedloden.com> <20141001202909.GG16215@hezmatt.org> <542C664E.7010209@gmail.com> Message-ID: <542C6F14.9010408@techmonkeys.org> On 10/01/2014 02:59 PM, Todd Underwood wrote: > read: http://www.xenproject.org/security-policy.html > > they have a sensible, commonly used security policy that involves private > notification to large customers in advance where it is practical and there > is not evidence of ongoing exploits in the wild. > > this is kind of incident handling 101 and shouldn't be surprising to anyone. > You don't have to be that large to get on the list. From jared at puck.nether.net Wed Oct 1 21:18:49 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 1 Oct 2014 17:18:49 -0400 Subject: AWS EC2 us-west-2 reboot In-Reply-To: References: <20140924204138.5a6bdf1d.reed@reedloden.com> <20141001202909.GG16215@hezmatt.org> <542C664E.7010209@gmail.com> Message-ID: <09BA5A2F-1277-4F57-8F06-8D42B0374254@puck.nether.net> > On Oct 1, 2014, at 4:59 PM, Todd Underwood wrote: > > this is kind of incident handling 101 and shouldn't be surprising to anyone. There’s always people who feel “left out of the loop” when these things occur. I’ve found there’s no one location for centralized data after many years of doing this from the ASN.1/ILMI days to present. It requires being professional and engaging when most people just want to consume the derived data. Having found a few of these issues myself over the years, the best bugs are the ones where the advisory comes out after the fixed software is broadly available and deployed. Nothing will be perfect as people always like their legacy system that requires no work, but in reality, there is no such thing. - Jared From Luke.Parrish at Suddenlink.com Wed Oct 1 21:10:58 2014 From: Luke.Parrish at Suddenlink.com (Parrish, Luke) Date: Wed, 1 Oct 2014 21:10:58 +0000 Subject: mediastream/vyve noc information/number? Message-ID: <10AB04B9CE55DF4AA248C0388F4ED464641BC569@SDLDALPWEMB07.suddenlink.cequel3.com> Anyone have contact information for Mediastream/Vyve Broadband NOC? Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455 ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. ________________________________ From swmike at swm.pp.se Thu Oct 2 10:10:39 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 2 Oct 2014 12:10:39 +0200 (CEST) Subject: large BCP38 compliance testing Message-ID: Hi, To fix a lot of the DDOS attacks going on, we need to make sure BCP38 compliance goes up. Only way to do this I can think of, is large scale BCP38 testing. One way of doing this, is to have large projects such as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement something that would spoof 1 packet per day or something to a known destination, and in this packet the "real" source address of the packet is included. I have been getting pushback from people that this might be "illegal". Could anyone please tell me what's illegal about trying to send a packet with a random source address? If we can get consensus in the operational world that this is actually ok, would that help organisations to implement this kind of testing. I could see vendors implement a test like "help verify network stability and compliance, these tests are anonymous" checkbox during the initial install, or something like this. Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS attacks, asking people to fix their open resolvers, NTP servers etc, when the actual culprit is that some networks in the world don't implement BCP38? -- Mikael Abrahamsson email: swmike at swm.pp.se From joly at punkcast.com Thu Oct 2 10:11:14 2014 From: joly at punkcast.com (Joly MacFie) Date: Thu, 2 Oct 2014 06:11:14 -0400 Subject: Marconi Society Symposium today Message-ID: will be webcast. http://isoc-ny.org/p2/7040 -- --------------------------------------------------------------- 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 swmike at swm.pp.se Thu Oct 2 10:12:41 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 2 Oct 2014 12:12:41 +0200 (CEST) Subject: large BCP38 compliance testing In-Reply-To: References: Message-ID: On Thu, 2 Oct 2014, Mikael Abrahamsson wrote: > these tests are anonymous" checkbox during the initial install, or > something like this. After posting this, I was pointed to http://spoofer.cmand.org . This seems like the exact thing I would like to test. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Thu Oct 2 10:28:30 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 02 Oct 2014 11:28:30 +0100 Subject: large BCP38 compliance testing In-Reply-To: References: Message-ID: <542D28CE.9070505@foobar.org> On 02/10/2014 11:10, Mikael Abrahamsson wrote: > Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS > attacks, asking people to fix their open resolvers, NTP servers etc, when > the actual culprit is that some networks in the world don't implement BCP38? ntp monlist / dnssec abuse can provide ~30x amplification. So if you can find ten 1G links anywhere in the world which aren't protected with BGP38 filtering, you can initiate a mostly untraceable 300G DDoS. This shouldn't stop us from finding, then naming and shaming operators who don't use bcp38, but we also need to maintain realistic expectations about how successful it's going to be. It would probably be more productive to pressurise transit providers to enforce bcp38 on their customer links. Nick From jerome at ceriz.fr Thu Oct 2 11:23:42 2014 From: jerome at ceriz.fr (=?windows-1252?Q?J=E9r=F4me_Nicolle?=) Date: Thu, 02 Oct 2014 13:23:42 +0200 Subject: large BCP38 compliance testing In-Reply-To: <542D28CE.9070505@foobar.org> References: <542D28CE.9070505@foobar.org> Message-ID: <542D35BE.40304@ceriz.fr> Le 02/10/2014 12:28, Nick Hilliard a écrit : > It would probably be more productive to pressurise transit providers to > enforce bcp38 on their customer links. This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense. Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? What are the known downsides to uRPF-strict ? When buying from transits, you either update your IRR for automatic perfix-filter generation on your transit's side, or start by a "BGP over SMTP" session. While the former could generate ACLs from a template, the latter will be prone to human error. And still, how many of us _really_ ensure their IRRs are always up-to-date ? Next in line : IXPs. You never really know what routes will be available or has to be filtered when 800+ AS, most with customers also using BGP, starts talking to the same route-server. Or maybe, the route-server could provide a flowspec AFI to send filters AND routes simultaneously. Would you trust it ? Will your router have enough silicon-horse-power to match both IP _and_ L2 headers at line-rate ? BCP38 aims at spoof prevention by filtering as close to the source as possible. Implementation on network's edge looks to me like a tricky one. Sharing the load amongst CPE is the best practice, and could be considered a requirement enforced by transit providers. Or shouldn't it ? Best regards, -- Jérôme Nicolle From bgreene at senki.org Thu Oct 2 11:29:04 2014 From: bgreene at senki.org (Barry Greene) Date: Thu, 2 Oct 2014 18:29:04 +0700 Subject: large BCP38 compliance testing In-Reply-To: <542D35BE.40304@ceriz.fr> References: <542D28CE.9070505@foobar.org> <542D35BE.40304@ceriz.fr> Message-ID: <2CF11E90-23CC-4DB2-BA78-9915C379580D@senki.org> On Oct 2, 2014, at 6:23 PM, Jérôme Nicolle wrote: > > > Le 02/10/2014 12:28, Nick Hilliard a écrit : >> It would probably be more productive to pressurise transit providers to >> enforce bcp38 on their customer links. > > This. But let me ask you, how many transit provider actually implement > strict prefix-filtering ? I've seen many using a max-prefix as their > sole defense. > > Now, let's consider what you want is to match an interface ACL to > prefixes received on a BGP session runing through the same interface. > Ain't that what uRPF-strict is all about ? uRPF Strict mode is NOT a tool to use on the transit connections. It was built for the SP-Customer connections. uRPF VRF mode _was_ built for the transit connections. You can take all the prefixes received from the peer and stick them into a VRF. You can then check all the incoming packet source addresses against that list. If there is no match, then it was not in the BGP advertisements. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Thu Oct 2 11:35:35 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 02 Oct 2014 12:35:35 +0100 Subject: large BCP38 compliance testing In-Reply-To: <542D35BE.40304@ceriz.fr> References: <542D28CE.9070505@foobar.org> <542D35BE.40304@ceriz.fr> Message-ID: <542D3887.5000701@foobar.org> On 02/10/2014 12:23, Jérôme Nicolle wrote: > This. But let me ask you, how many transit provider actually implement > strict prefix-filtering ? I've seen many using a max-prefix as their > sole defense. Plenty do and have no back-end capability to handle this, other than email updates. > Now, let's consider what you want is to match an interface ACL to > prefixes received on a BGP session runing through the same interface. > Ain't that what uRPF-strict is all about ? What are the known downsides > to uRPF-strict ? Your bgp announcement to your upstream is not guaranteed to be there all the time. E.g. if you're doing maintenance and stop announcing bgp to your upstream for inbound traffic, but still want to depend on it for outbound traffic, urpf will trash things. urpf is only feasible for statically configured hand-offs. > When buying from transits, you either update your IRR for automatic > perfix-filter generation on your transit's side, or start by a "BGP over > SMTP" session. While the former could generate ACLs from a template, the > latter will be prone to human error. And still, how many of us _really_ > ensure their IRRs are always up-to-date ? This only happens when there is a reason to do so. > Next in line : IXPs. You never really know what routes will be available > or has to be filtered when 800+ AS, most with customers also using BGP, > starts talking to the same route-server. Or maybe, the route-server > could provide a flowspec AFI to send filters AND routes simultaneously. IXPs are more difficult, but if your IXP is running a route server, they should be implementing strict prefix filtering. At least, this puts pressure on IXP participants to register their prefix at their local irrdb. > Would you trust it ? Will your router have enough silicon-horse-power to > match both IP _and_ L2 headers at line-rate ? probably yes on most routers with dedicated hardware for this, but it will depend on the number of acl entries. > BCP38 aims at spoof prevention by filtering as close to the source as > possible. Implementation on network's edge looks to me like a tricky > one. Sharing the load amongst CPE is the best practice, and could be > considered a requirement enforced by transit providers. Or shouldn't it ? urpf is appropriate for the ISP last hop. Static filters are suitable for the transit provider connecting that ISP to the rest of the network. Nick From ahebert at pubnix.net Thu Oct 2 12:16:57 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 02 Oct 2014 08:16:57 -0400 Subject: large BCP38 compliance testing In-Reply-To: References: Message-ID: <542D4239.1020203@pubnix.net> On 10/02/14 06:10, Mikael Abrahamsson wrote: > > Hi, > > To fix a lot of the DDOS attacks going on, we need to make sure BCP38 > compliance goes up. Only way to do this I can think of, is large scale > BCP38 testing. One way of doing this, is to have large projects such > as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement > something that would spoof 1 packet per day or something to a known > destination, and in this packet the "real" source address of the > packet is included. A proof of concept could be as simple as a basic BCP38 test implemented into the OpenWRT/DD-WRT UI. > I have been getting pushback from people that this might be "illegal". > Could anyone please tell me what's illegal about trying to send a > packet with a random source address? You could reserve yourself an IP address in a subnet you own and use that as a source IP for testing. > If we can get consensus in the operational world that this is actually > ok, would that help organisations to implement this kind of testing. I > could see vendors implement a test like "help verify network stability > and compliance, these tests are anonymous" checkbox during the initial > install, or something like this. In short: . Test Client call the BCP38 Test Server for a Token; . Test Client send a test packet with that token in the payload; . Test Client call the BCP38 Test Server with the Token and the server returns pass of fail which is displayed back in the CPE UI; While being over simplified, BCP38.org has some perl scripts from last year NTP DDoS rush that actually does part of this. If the initial proof of concept get traction, a more complete BCP38 test set can be implemented, there is a few projects out there that could be approached for it. > Why isn't this being done? Why are we complaining about 300 gigabit/s > DDOS attacks, asking people to fix their open resolvers, NTP servers > etc, when the actual culprit is that some networks in the world don't > implement BCP38? "most networks in the world" BCP38 compliance is the exception not the norm. PS: About that uRPF Convo, we could dump all that knowledges into lets say... some comprehensive wiki page maybe =D That way when the topic arise we could just link to it. From rdobbins at arbor.net Thu Oct 2 12:37:55 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Oct 2014 19:37:55 +0700 Subject: large BCP38 compliance testing In-Reply-To: <542D4239.1020203@pubnix.net> References: <542D4239.1020203@pubnix.net> Message-ID: <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> On Oct 2, 2014, at 7:16 PM, Alain Hebert wrote: > BCP38 compliance is the exception not the norm. I'm not sure that's actually the case, practically-speaking. NAT is an awful thing for many reasons, and it's negative in terms of its overall impact on security, but there's one actual benefit from it; it is effectively a form of anti-spoofing. The prevalence of NAT on consumer broadband access networks means that those networks do not generally emit spoofed packets. The same goes for many SME networks, even though they oughtn't to be running NAT in front of their servers. My guess is that the majority, if not all, of the reflection/amplification attacks we see are actually initiated from servers under the control of attackers and residing on hosting/co-location IDC networks which don't enforce anti-spoofing at the access, distribution, or peering/transit portions of their topologies. Some of these servers are tied into so-called 'booter' systems, whereas others are linked into more conventional C&C under the direct control of attackers, while still others are utilized to launch attacks 'by hand', as it were. Those networks are unmanaged and are likely to remain so (or are so-called 'bulletproof' networks catering to criminals). Their peers/upstream transits likewise are not enforcing anti-spoofing on ingress, nor are they monitoring traffic originating from these networks as it ingresses their own networks (and in any event, the traffic volume of the spoofed packets on the attack source - reflector/amplifier leg is relatively small). So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From ahebert at pubnix.net Thu Oct 2 12:54:07 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 02 Oct 2014 08:54:07 -0400 Subject: large BCP38 compliance testing In-Reply-To: <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> References: <542D4239.1020203@pubnix.net> <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> Message-ID: <542D4AEF.5040907@pubnix.net> On 10/02/14 08:37, Roland Dobbins wrote: > On Oct 2, 2014, at 7:16 PM, Alain Hebert wrote: > >> BCP38 compliance is the exception not the norm. > I'm not sure that's actually the case, practically-speaking. > > NAT is an awful thing for many reasons, and it's negative in terms of its overall impact on security, but there's one actual benefit from it; it is effectively a form of anti-spoofing. > > The prevalence of NAT on consumer broadband access networks means that those networks do not generally emit spoofed packets. The same goes for many SME networks, even though they oughtn't to be running NAT in front of their servers. You are right on that point, I keep forgetting about the little man :( My mindset was set on DDoS and not C&C/SPAM/etc. > My guess is that the majority, if not all, of the reflection/amplification attacks we see are actually initiated from servers under the control of attackers and residing on hosting/co-location IDC networks which don't enforce anti-spoofing at the access, distribution, or peering/transit portions of their topologies. Some of these servers are tied into so-called 'booter' systems, whereas others are linked into more conventional C&C under the direct control of attackers, while still others are utilized to launch attacks 'by hand', as it were. We had the same experience where you get a 1Mbps steam of DDoS amplification start on the 15th and end abruptly on the 30th at 23h55m (CC report cycle/reject is often around 15 days). Then on the 5th and end 15 days later... for a few month in a row. > Those networks are unmanaged and are likely to remain so (or are so-called 'bulletproof' networks catering to criminals). Their peers/upstream transits likewise are not enforcing anti-spoofing on ingress, nor are they monitoring traffic originating from these networks as it ingresses their own networks (and in any event, the traffic volume of the spoofed packets on the attack source - reflector/amplifier leg is relatively small). > > So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön From rdobbins at arbor.net Thu Oct 2 13:04:12 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Oct 2014 20:04:12 +0700 Subject: large BCP38 compliance testing In-Reply-To: <542D4AEF.5040907@pubnix.net> References: <542D4239.1020203@pubnix.net> <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> <542D4AEF.5040907@pubnix.net> Message-ID: <11206205-29BE-4870-B21B-D1AF5BED1817@arbor.net> On Oct 2, 2014, at 7:54 PM, Alain Hebert wrote: > My mindset was set on DDoS and not C&C/SPAM/etc. My point is that the ability to launch reflection/amplification DDoS attacks (as well as spoofed SYN-floods, and so forth) is dependent upon the ability to spoof packets, and that my hunch is that there're a relatively small number of networks from which the spoofed attack traffic is emitted. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From eric.sieg at gmail.com Thu Oct 2 14:34:00 2014 From: eric.sieg at gmail.com (Eric Sieg) Date: Thu, 2 Oct 2014 10:34:00 -0400 Subject: Requesting a Global Crossing contact Message-ID: Could someone from Global Crossing reach out to me please? Just need to confirm you see a route and haven't had any luck accessing your looking glass in the last 24 hours. Thanks! From streiner at cluebyfour.org Thu Oct 2 15:02:40 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 2 Oct 2014 11:02:40 -0400 (EDT) Subject: Requesting a Global Crossing contact In-Reply-To: References: Message-ID: On Thu, 2 Oct 2014, Eric Sieg wrote: > Could someone from Global Crossing reach out to me please? Just need to > confirm you see a route and haven't had any luck accessing your looking > glass in the last 24 hours. Have you tried reaching out to anyone at Level3? Level3 acquired GX 3 years ago. jms From robachevsky at isoc.org Thu Oct 2 15:31:43 2014 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Thu, 2 Oct 2014 17:31:43 +0200 Subject: large BCP38 compliance testing In-Reply-To: <542D28CE.9070505@foobar.org> References: <542D28CE.9070505@foobar.org> Message-ID: <542D6FDF.6030500@isoc.org> Nick Hilliard wrote on 02/10/14 12:28: > This shouldn't stop us from finding, then naming and shaming operators > who don't use bcp38, but we also need to maintain realistic expectations > about how successful it's going to be. This feels indeed like boiling the ocean, but what are the alternatives, given that we are looking at a fundamental feature in the Internet routing system - source address has no practical significance? But on another side, how easy it is to comply? The best documentation I found was “RIPE Anti-Spoofing Task Force HOW-TO”, http://www.ripe.net/ripe/docs/ripe-431, but even that doesn't cover all cases and needs updating. Are there are other useful references, besides bcp38/84 and bcp38.info? Andrei From Valdis.Kletnieks at vt.edu Thu Oct 2 15:54:01 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Oct 2014 11:54:01 -0400 Subject: large BCP38 compliance testing In-Reply-To: Your message of "Thu, 02 Oct 2014 12:10:39 +0200." References: Message-ID: <43245.1412265241@turing-police.cc.vt.edu> On Thu, 02 Oct 2014 12:10:39 +0200, Mikael Abrahamsson said: > I have been getting pushback from people that this might be "illegal". > Could anyone please tell me what's illegal about trying to send a packet > with a random source address? The *real* problem isn't the testing. It's the assumption that you can actually *do* anything useful with this data. Name-n-shame probably won't get us far - and the way the US works, if there's a large cartel of BCP38-compliant providers calling out the offenders by name, you might encounter an offender that finds it cheaper to send a lawyer chanting 'restraint of trade!' or similar rather than actually fixing their problem.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ryan.landry at gmail.com Thu Oct 2 16:03:15 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 2 Oct 2014 09:03:15 -0700 Subject: cogent update suppression, and routing loops Message-ID: hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan From contact at winterei.se Thu Oct 2 16:08:00 2014 From: contact at winterei.se (Paul S.) Date: Fri, 03 Oct 2014 01:08:00 +0900 Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: <542D7860.7060701@winterei.se> First time I'm seeing it, and I've been a Cogent client for quite a while. Have you tried getting in touch with their NOC yet? They're one of the most responsive in the industry. On 10/3/2014 午前 01:03, ryanL wrote: > hi. relatively new cogent customer. is what i've stated in my subject line > kinda standard fare with them? > > i've discovered that when i advertise a /24 from inside a larger /22 to XO, > (who peers with cogent), and then pull the /24 some time later, that cogent > holds onto the /24 and then bounces packets around in their network a bunch > of times for upwards of 8-10 minutes until they finally yank it. this > effectively blackholes traffic to my /24 for anyone that is using a path > thru cogent. > > example: http://ryry.foursquare.com/image/0e0K1K0t0W2M > > it's been a bit of a frustrating experience talking to their noc to > demonstrate it, but i'm able to duplicate it on demand. even pushing routes > using their communities to offload the circuit takes forever to propagate > even on their own looking-glasses. > > thx > > ryan From rdobbins at arbor.net Thu Oct 2 16:08:17 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Oct 2014 23:08:17 +0700 Subject: large BCP38 compliance testing In-Reply-To: <43245.1412265241@turing-police.cc.vt.edu> References: <43245.1412265241@turing-police.cc.vt.edu> Message-ID: <702DFCCA-C04A-4861-8455-823D66C3742F@arbor.net> On Oct 2, 2014, at 10:54 PM, Valdis.Kletnieks at vt.edu wrote: > you might encounter an offender that finds it cheaper to send a lawyer chanting 'restraint of trade!' or similar rather than actually fixing their problem.... In several jurisdictions in APAC, at least, truth is not a defense against *criminal* defamation charges, much less in civil suits. And there are more than a few networks in APAC which haven't implemented source-address validation to the degree possible . . . ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ryan.landry at gmail.com Thu Oct 2 16:41:25 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 2 Oct 2014 09:41:25 -0700 Subject: cogent update suppression, and routing loops In-Reply-To: <542D7860.7060701@winterei.se> References: <542D7860.7060701@winterei.se> Message-ID: as stated, yep. i was on the phone with them for over three hours yesterday. On Thu, Oct 2, 2014 at 9:08 AM, Paul S. wrote: > First time I'm seeing it, and I've been a Cogent client for quite a while. > > Have you tried getting in touch with their NOC yet? They're one of the > most responsive in the industry. > > > On 10/3/2014 午前 01:03, ryanL wrote: > >> hi. relatively new cogent customer. is what i've stated in my subject line >> kinda standard fare with them? >> >> i've discovered that when i advertise a /24 from inside a larger /22 to >> XO, >> (who peers with cogent), and then pull the /24 some time later, that >> cogent >> holds onto the /24 and then bounces packets around in their network a >> bunch >> of times for upwards of 8-10 minutes until they finally yank it. this >> effectively blackholes traffic to my /24 for anyone that is using a path >> thru cogent. >> >> example: http://ryry.foursquare.com/image/0e0K1K0t0W2M >> >> it's been a bit of a frustrating experience talking to their noc to >> demonstrate it, but i'm able to duplicate it on demand. even pushing >> routes >> using their communities to offload the circuit takes forever to propagate >> even on their own looking-glasses. >> >> thx >> >> ryan >> > > From ryan.landry at gmail.com Thu Oct 2 16:44:26 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 2 Oct 2014 09:44:26 -0700 Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: i still advertise the aggregate as a backing route. one reason i might like advertising a /24 is (usually) it's a nice way to gently attract return traffic down a certain path so i can do maintenance on the other side. plenty of other ways to do this, i know (prepending, communities, etc). On Thu, Oct 2, 2014 at 9:17 AM, Peter Persson wrote: > Just a stupid question. > Why do you announce a /24 of a /22? Why not announce the whole /22 > directly? > > Regards, > Peter > > 2014-10-02 18:03 GMT+02:00 ryanL : > >> hi. relatively new cogent customer. is what i've stated in my subject line >> kinda standard fare with them? >> >> i've discovered that when i advertise a /24 from inside a larger /22 to >> XO, >> (who peers with cogent), and then pull the /24 some time later, that >> cogent >> holds onto the /24 and then bounces packets around in their network a >> bunch >> of times for upwards of 8-10 minutes until they finally yank it. this >> effectively blackholes traffic to my /24 for anyone that is using a path >> thru cogent. >> >> example: http://ryry.foursquare.com/image/0e0K1K0t0W2M >> >> it's been a bit of a frustrating experience talking to their noc to >> demonstrate it, but i'm able to duplicate it on demand. even pushing >> routes >> using their communities to offload the circuit takes forever to propagate >> even on their own looking-glasses. >> >> thx >> >> ryan >> > > From eric.sieg at gmail.com Thu Oct 2 16:53:22 2014 From: eric.sieg at gmail.com (Eric Sieg) Date: Thu, 2 Oct 2014 12:53:22 -0400 Subject: Requesting a Global Crossing contact In-Reply-To: References: Message-ID: fyi, Level3 was able to help me out. (Wasn't sure how integrated the two networks were as the network I wanted checked was glbx's legacy AS.) On Thu, Oct 2, 2014 at 10:34 AM, Eric Sieg wrote: > Could someone from Global Crossing reach out to me please? Just need to > confirm you see a route and haven't had any luck accessing your looking > glass in the last 24 hours. > > Thanks! > From jared at puck.nether.net Thu Oct 2 18:18:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 2 Oct 2014 14:18:03 -0400 Subject: large BCP38 compliance testing In-Reply-To: <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> References: <542D4239.1020203@pubnix.net> <8BDA8114-FB1C-4810-869D-AD1A99266D83@arbor.net> Message-ID: <68157CA1-2187-4BAD-93BA-F40F0499F13E@puck.nether.net> > On Oct 2, 2014, at 8:37 AM, Roland Dobbins wrote: > > So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. We have not seen support from other customers of our vendors for these features in RFI/RFP. It has taken us sometimes a year (or more) to get software fixes for uRPF related defects. The network performance can be impacted for all users due to the penalty by turning on uRPF as well, so it’s not even technically viable if you want line-rate from certain hardware sets. (See RFI/RFP). I’ve tried to collect a list of other interested parties to include this in their purchasing process with 0 takers so have put this on the back burner and just kept measuring networks that permit spoofed packets instead. It’s like any other things (e.g.: BGP hygiene), many people don’t invest the time/though/resources to cause the necessary impact. - Jared From brak at gameservers.com Thu Oct 2 18:24:18 2014 From: brak at gameservers.com (Brian Rak) Date: Thu, 02 Oct 2014 14:24:18 -0400 Subject: large BCP38 compliance testing In-Reply-To: References: Message-ID: <542D9852.3020902@gameservers.com> On 10/2/2014 6:10 AM, Mikael Abrahamsson wrote: > > Hi, > > To fix a lot of the DDOS attacks going on, we need to make sure BCP38 > compliance goes up. Only way to do this I can think of, is large scale > BCP38 testing. One way of doing this, is to have large projects such > as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement > something that would spoof 1 packet per day or something to a known > destination, and in this packet the "real" source address of the > packet is included. > > I have been getting pushback from people that this might be "illegal". > Could anyone please tell me what's illegal about trying to send a > packet with a random source address? > > If we can get consensus in the operational world that this is actually > ok, would that help organisations to implement this kind of testing. I > could see vendors implement a test like "help verify network stability > and compliance, these tests are anonymous" checkbox during the initial > install, or something like this. > > Why isn't this being done? Why are we complaining about 300 gigabit/s > DDOS attacks, asking people to fix their open resolvers, NTP servers > etc, when the actual culprit is that some networks in the world don't > implement BCP38? > A lot of the discussion on BCP38 seems to be around providers who are unintentionally allowing IP spoofing. What about providers who knowingly allow IP spoofing, because it's profitable? There's a provider that basically caters to the DDOS-as-a-service industry by selling servers with unmetered connections, where they allow IP spoofing. (If you've ever looked into this at all, you know exactly who I'm talking about). From rdobbins at arbor.net Thu Oct 2 18:34:14 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 3 Oct 2014 01:34:14 +0700 Subject: large BCP38 compliance testing In-Reply-To: <542D9852.3020902@gameservers.com> References: <542D9852.3020902@gameservers.com> Message-ID: <6EE7FC04-2BCB-4AF4-9283-6FC52E306C1D@arbor.net> On Oct 3, 2014, at 1:24 AM, Brian Rak wrote: > What about providers who knowingly allow IP spoofing, because it's profitable? Ultimately, the only way to even possibly try to get a handle on this facet of the problem may be via lawsuits; in many jurisdictions, the burden of proof is lower for the plaintiffs in a civil case than it is for prosecutors in criminal cases. The questions of evidence, standing, jurisdiction, provable damages, et. al. then come into play . . . and when those organizations are located in areas where the rule of law isn't particularly strong, it complicates matters further. There are precedents for extraterritorial legal suits, but unless there are assets that can be seized in the event of a verdict for the plaintiff, it's unclear how much actual impact they would have. [Note: IANAL, nor do I play one on television. All of the above is uninformed speculation and may be completely wrong.] ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From jlewis at lewis.org Thu Oct 2 22:19:41 2014 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 2 Oct 2014 18:19:41 -0400 (EDT) Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: On Thu, 2 Oct 2014, ryanL wrote: > hi. relatively new cogent customer. is what i've stated in my subject line > kinda standard fare with them? > > i've discovered that when i advertise a /24 from inside a larger /22 to XO, > (who peers with cogent), and then pull the /24 some time later, that cogent > holds onto the /24 and then bounces packets around in their network a bunch > of times for upwards of 8-10 minutes until they finally yank it. this > effectively blackholes traffic to my /24 for anyone that is using a path > thru cogent. Perhaps related, I made an as-path prepend change on a route advertised to Cogent yesterday and noticed it took about 10 minutes for that change to propagate throughout Cogent's network and be visible on route-views. A moment later, I did the same thing with another carrier, and got the expected nearly instant gratification. Perhaps they've got a bunch of routers configured with minimum-advertisement-interval to batch the BGP updates and if you're unlucky with the timing, it can take a while for routes/changes to percolate through their network? Imagine driving down a long road, where every traffic light turns red just before you get to the intersection. Wait a minute here, wait a minute there... ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rsk at gsp.org Thu Oct 2 22:47:54 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 2 Oct 2014 18:47:54 -0400 Subject: large BCP38 compliance testing In-Reply-To: <542D9852.3020902@gameservers.com> References: <542D9852.3020902@gameservers.com> Message-ID: <20141002224754.GA7606@gsp.org> On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote: > What about providers who knowingly allow IP spoofing, because it's > profitable? What about providers who knowingly host massive spam operations, because it's profitable? As in: http://www.spamhaus.org/statistics/networks/ We've been down this road before. Unless there is prompt, concerted, collective action (as there was AGIS) then there is zero reason for those behind such operations to do anything but keep collecting dirty money. So it's all good and well to *know* where the problems are: that's useful. But if the goal is to actually make the problems go away, then that'll require fingers on keyboards implementing null routing, firewalling, blacklisting etc. ---rsk From marka at isc.org Thu Oct 2 22:54:32 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 03 Oct 2014 08:54:32 +1000 Subject: large BCP38 compliance testing In-Reply-To: Your message of "Thu, 02 Oct 2014 18:47:54 -0400." <20141002224754.GA7606@gsp.org> References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> Message-ID: <20141002225433.59C7720AF55D@rock.dv.isc.org> In message <20141002224754.GA7606 at gsp.org>, Rich Kulawiec writes: > On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote: > > What about providers who knowingly allow IP spoofing, because it's > > profitable? > > What about providers who knowingly host massive spam operations, because > it's profitable? As in: > > http://www.spamhaus.org/statistics/networks/ > > We've been down this road before. Unless there is prompt, concerted, > collective action (as there was AGIS) then there is zero reason for those > behind such operations to do anything but keep collecting dirty money. > > So it's all good and well to *know* where the problems are: that's > useful. But if the goal is to actually make the problems go away, > then that'll require fingers on keyboards implementing null routing, > firewalling, blacklisting etc. Or it will require legislation and I will assure that whatever is written not be liked. On the other hand everyone one in the country will be in the same boat. > ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tony at wicks.co.nz Fri Oct 3 01:02:31 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 3 Oct 2014 14:02:31 +1300 Subject: DDOS - Law enforcement Message-ID: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> Hi All, I just thought I would throw a little stone out here onto towards all the law enforcement people who are inevitably watching this list. As someone who, like most of the others on this list has to deal with the effects of scumbags who send DDOS attacks towards my networks, It amazes me how you cannot put more effort into the blatant DDOS for hire platforms that are readily available to anyone. I mean how can these sites be allowed to continue unmolested when you can spend so much effort on P2P platforms ? I am referring to in particular - http://top10booters.com/ etc. How blatant do these scumbags have to be, they are even using ".com" addresses ! From morrowc.lists at gmail.com Fri Oct 3 01:09:37 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Oct 2014 18:09:37 -0700 Subject: DDOS - Law enforcement In-Reply-To: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> References: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> Message-ID: On Thu, Oct 2, 2014 at 6:02 PM, Tony Wicks wrote: > . I mean how can these sites be allowed to > continue unmolested when you can spend so much effort on P2P platforms You probably have to consider the amount of lobbying money sent toward govts in your equation. Perhaps if you also lobbied the gov'ts in a similar manner there would be resolution you'd like. From jcurran at arin.net Fri Oct 3 02:40:36 2014 From: jcurran at arin.net (John Curran) Date: Fri, 3 Oct 2014 02:40:36 +0000 Subject: Public Policy Consultation at NANOG 62 & ARIN 34 Meeting! References: <542D88D9.3030203@arin.net> Message-ID: <0F0F3E59-F048-4DFF-9FD7-F57716FB40E3@corp.arin.net> NANOG Folks - There are a number of proposed changes to number resource policy in the ARIN region, and you'll have two opportunities to discuss these proposals next week in Baltimore (or remotely, as you prefer) The Public Policy Consultation within NANOG takes place on Tuesday morning from 9 to 1 PM; everyone is welcome (although preregistration is required if you are not already registered for NANOG.) The ARIN 34 Meeting will follow NANOG on Thursday and Friday; we will have discussions of policy changes, as well as ARIN fee schedule, changes in the stewardship of the IANA functions, and more. Information on ARIN registration is also included in the attached message. I look forward to seeing everyone in Baltimore! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] The PPC @ NANOG 62 & ARIN 34 Will Be Here Soon – Get Ready! Date: October 2, 2014 at 1:18:17 PM EDT To: > Next week will be busy! With the Public Policy Consultation (PPC) at NANOG 62 and ARIN 34 Public Policy and Members Meeting, we will be in the thick of important community discussions on ten policy proposals. * Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements * Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] * Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers * Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers * Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification * Draft Policy ARIN-2014-1: Out of Region Use * Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update * Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate * Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments * Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization Whether you plan to join us online or in-person, we want to make sure you are ready. To help you prepare for the meeting, ARIN has published all of the meeting materials online for you to review or download before the meeting begins. Just visit: https://www.arin.net/ppc_materials or https://www.arin.net/ARIN34_materials Copies of the presentations of the meetings will also be posted at the above URLs once the meeting has started, as they are available. We hope to see you in Baltimore, but if you are unable to join us in person, be sure to keep up with us by participating remotely! View the agenda, learn more about remote participation, and register today by visiting: The PPC at NANOG 62: https://www.arin.net/ppcnanog62 ARIN 34: https://www.arin.net/ARIN34 Please contact us at info at arin.net if you have any questions. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From robachevsky at isoc.org Fri Oct 3 09:01:23 2014 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Fri, 3 Oct 2014 11:01:23 +0200 Subject: large BCP38 compliance testing In-Reply-To: <20141002224754.GA7606@gsp.org> References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> Message-ID: <542E65E3.90703@isoc.org> Rich Kulawiec wrote on 03/10/14 00:47: > We've been down this road before. Unless there is prompt, concerted, > collective action (as there was AGIS) then there is zero reason for those > behind such operations to do anything but keep collecting dirty money. There is, please join: http://www.routingmanifesto.org/manrs/ Andrei From corbe at corbe.net Fri Oct 3 14:33:40 2014 From: corbe at corbe.net (Daniel Corbe) Date: Fri, 03 Oct 2014 10:33:40 -0400 Subject: Equinix Sales Message-ID: Equinix Sales seem impossible to reach. Should I just give up and go through a sales agent or can someone from Equinix sales contact me off-list? From mhuff at ox.com Fri Oct 3 14:47:21 2014 From: mhuff at ox.com (Matthew Huff) Date: Fri, 3 Oct 2014 14:47:21 +0000 Subject: NJ Data center equipment movers Message-ID: <33eb6391bee14aaf81a9884dfb6fc72e@pur-vm-exch13n1.ox.com> I'm looking to have some equipment (2 x HP C7000 blade chassis ( each with 16 blades), 2 x Cisco 7600, and some small misc equipment) from a datacenter in Mahwah, NJ to Secaucus, NJ. Anyone recommend someone? From Valdis.Kletnieks at vt.edu Fri Oct 3 14:52:08 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Oct 2014 10:52:08 -0400 Subject: DDOS - Law enforcement In-Reply-To: Your message of "Fri, 03 Oct 2014 14:02:31 +1300." <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> References: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> Message-ID: <39423.1412347928@turing-police.cc.vt.edu> On Fri, 03 Oct 2014 14:02:31 +1300, "Tony Wicks" said: > effects of scumbags who send DDOS attacks towards my networks, It amazes me > how you cannot put more effort into the blatant DDOS for hire platforms that > are readily available to anyone. I mean how can these sites be allowed to > continue unmolested when you can spend so much effort on P2P platforms ? Remember that high-level resources aren't dedicated based on amount of actual economic damage, but amount of lobbying effort/money. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ahebert at pubnix.net Fri Oct 3 14:59:28 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 03 Oct 2014 10:59:28 -0400 Subject: DDOS - Law enforcement In-Reply-To: <39423.1412347928@turing-police.cc.vt.edu> References: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> <39423.1412347928@turing-police.cc.vt.edu> Message-ID: <542EB9D0.2000107@pubnix.net> On 10/03/14 10:52, Valdis.Kletnieks at vt.edu wrote: > On Fri, 03 Oct 2014 14:02:31 +1300, "Tony Wicks" said: >> effects of scumbags who send DDOS attacks towards my networks, It amazes me >> how you cannot put more effort into the blatant DDOS for hire platforms that >> are readily available to anyone. I mean how can these sites be allowed to >> continue unmolested when you can spend so much effort on P2P platforms ? > Remember that high-level resources aren't dedicated based on amount of > actual economic damage, but amount of lobbying effort/money. Well, Last time I had to deal with the people that passes for law enforcement around here. We where told to prouve 100k+ damage first before they even bother meeting us. I think millage/traction vary per jurisdiction. From Valdis.Kletnieks at vt.edu Fri Oct 3 15:11:33 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Oct 2014 11:11:33 -0400 Subject: DDOS - Law enforcement In-Reply-To: Your message of "Fri, 03 Oct 2014 10:59:28 -0400." <542EB9D0.2000107@pubnix.net> References: <007e01cfdea5$b73a5fe0$25af1fa0$@wicks.co.nz> <39423.1412347928@turing-police.cc.vt.edu> <542EB9D0.2000107@pubnix.net> Message-ID: <40481.1412349093@turing-police.cc.vt.edu> On Fri, 03 Oct 2014 10:59:28 -0400, Alain Hebert said: > We where told to prouve 100k+ damage first before they even bother > meeting us. Remember that a single iPod full of pirated music is $8 billion of damage. http://www.youtube.com/watch?v=GZadCj8O1-0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rsk at gsp.org Fri Oct 3 15:17:46 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 3 Oct 2014 11:17:46 -0400 Subject: large BCP38 compliance testing In-Reply-To: <20141002225433.59C7720AF55D@rock.dv.isc.org> References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> <20141002225433.59C7720AF55D@rock.dv.isc.org> Message-ID: <20141003151745.GA24228@gsp.org> On Fri, Oct 03, 2014 at 08:54:32AM +1000, Mark Andrews wrote: > Or it will require legislation and I will assure that whatever is > written not be liked. On the other hand everyone one in the country > will be in the same boat. I concur with you -- strongly. Legislation is not the answer, because (a) it only applies in limited jurisdictions and this is a global problem and (b) it will inevitably be written by those with the deepest pockets, see for example CAN-SPAM, crafted by and for spammers and their supporters. But legislation isn't necessary. Within limits (prescribed by contractual obligations) none of us are required to offer services to arbitrary parties. We *choose* to do so, by default, all day every day because that's why we have an Internet. But we're not *obligated* to do so: those services may be withheld in full or part at any time for any reason (or even without a reason). And this is where I quote the best thing I've ever read on this mailing list: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie Having observed, for example, the spam problem since its genesis, I can unequivocally state that the *only* thing that has ever addressed the problem (rather than merely addressing its symptoms) is SMTP blacklisting. Everything else has been ineffective, misdirected, wishful thinking. The same thing applies here: persistent, systemic sources of large-scale abuse via BCP-38 noncompliance are either: 1. Being operated by clueless, negligent, incompetent people or 2. Being operated by deliberately abusive people There are no other possibilities. (Note: "persistent, systemic". Transient, isolated problems happen to everyone and are not what I'm talking about here.) It's difficult to know which of those two are true via external observation, but it's not *necessary* to know: the appropriate remedial action remains the same in either case: stop giving them the means. ---rsk From nick at flhsi.com Fri Oct 3 16:09:18 2014 From: nick at flhsi.com (Nick Olsen) Date: Fri, 3 Oct 2014 12:09:18 -0400 Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: I've had the exact same thing happen. Recently, I removed a bunch of /24's that were member of a larger /20. We use to advertise the /24's to certain carriers for traffic engineering. I saw the exact same issue you're describing. I chocked it up to Slow BGP in their core. For instance, I removed the route from my session with them in Orlando. It would get removed from Orlando, But still exist in Jacksonville. And basically route loop coming in from the north. It'd land in JAX, And get forwarded to MCO. Which would then forward it back to JAX. 20-30 seconds later, it would get removed from JAX, and I'd see the same behavior between JAX and ATL. It took a 4-5 minutes in my experience for the route to finally leave the Cogent network. I lessened the blow by making Cogent the first peer I'd remove the /24 from. Leaving the other /24's out there via the other carriers. So only those that chose cogent as the most direct route felt the unintentional blackhole. Other carriers removed almost instantly as expected. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "ryanL" Sent: Thursday, October 02, 2014 12:07 PM To: "North American Network Operators Group" Subject: cogent update suppression, and routing loops hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan From nicotine at warningg.com Fri Oct 3 17:56:22 2014 From: nicotine at warningg.com (Brandon Ewing) Date: Fri, 3 Oct 2014 12:56:22 -0500 Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: <20141003175622.GB14967@radiological.warningg.com> On Thu, Oct 02, 2014 at 09:03:15AM -0700, ryanL wrote: > (who peers with cogent), and then pull the /24 some time later, that cogent > holds onto the /24 and then bounces packets around in their network a bunch > of times for upwards of 8-10 minutes until they finally yank it. this > effectively blackholes traffic to my /24 for anyone that is using a path > thru cogent. Maybe running into some non-standard BGP Advertisement intervals inside Cogent's network? Might be running a lot of sub-ASes inside the confederation, and having to wait multiple advertisement intervals for full propagation. https://routingfreak.wordpress.com/tag/minimum-route-advertisement-interval/ -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cscora at apnic.net Fri Oct 3 18:12:05 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Oct 2014 04:12:05 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201410031812.s93IC5Kw028151@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, TRNOG, 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 Oct, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 513366 Prefixes after maximum aggregation: 199005 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 252719 Total ASes present in the Internet Routing Table: 48192 Prefixes per ASN: 10.65 Origin-only ASes present in the Internet Routing Table: 36237 Origin ASes announcing only one prefix: 16367 Transit ASes present in the Internet Routing Table: 6144 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 118 Max AS path prepend of ASN ( 55644) 111 Prefixes from unregistered ASNs in the Routing Table: 1796 Unregistered ASNs in the Routing Table: 436 Number of 32-bit ASNs allocated by the RIRs: 7552 Number of 32-bit ASNs visible in the Routing Table: 5811 Prefixes from 32-bit ASNs in the Routing Table: 20513 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 345 Number of addresses announced to Internet: 2709985028 Equivalent to 161 /8s, 135 /16s and 23 /24s Percentage of available address space announced: 73.2 Percentage of allocated address space announced: 73.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176366 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 124949 Total APNIC prefixes after maximum aggregation: 36672 APNIC Deaggregation factor: 3.41 Prefixes being announced from the APNIC address blocks: 128774 Unique aggregates announced from the APNIC address blocks: 53389 APNIC Region origin ASes present in the Internet Routing Table: 4979 APNIC Prefixes per ASN: 25.86 APNIC Region origin ASes announcing only one prefix: 1189 APNIC Region transit ASes present in the Internet Routing Table: 856 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 118 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1115 Number of APNIC addresses announced to Internet: 734732608 Equivalent to 43 /8s, 203 /16s and 33 /24s Percentage of available APNIC address space announced: 85.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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, 150/8, 153/8, 163/8, 171/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: 170714 Total ARIN prefixes after maximum aggregation: 85222 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 172625 Unique aggregates announced from the ARIN address blocks: 80799 ARIN Region origin ASes present in the Internet Routing Table: 16372 ARIN Prefixes per ASN: 10.54 ARIN Region origin ASes announcing only one prefix: 6108 ARIN Region transit ASes present in the Internet Routing Table: 1697 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 215 Number of ARIN addresses announced to Internet: 1085100736 Equivalent to 64 /8s, 173 /16s and 82 /24s Percentage of available ARIN address space announced: 57.4 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125205 Total RIPE prefixes after maximum aggregation: 63502 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 130400 Unique aggregates announced from the RIPE address blocks: 82997 RIPE Region origin ASes present in the Internet Routing Table: 17747 RIPE Prefixes per ASN: 7.35 RIPE Region origin ASes announcing only one prefix: 8210 RIPE Region transit ASes present in the Internet Routing Table: 2904 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3091 Number of RIPE addresses announced to Internet: 659138692 Equivalent to 39 /8s, 73 /16s and 168 /24s Percentage of available RIPE address space announced: 95.8 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59835 Total LACNIC prefixes after maximum aggregation: 10728 LACNIC Deaggregation factor: 5.58 Prefixes being announced from the LACNIC address blocks: 68362 Unique aggregates announced from the LACNIC address blocks: 30503 LACNIC Region origin ASes present in the Internet Routing Table: 2342 LACNIC Prefixes per ASN: 29.19 LACNIC Region origin ASes announcing only one prefix: 648 LACNIC Region transit ASes present in the Internet Routing Table: 458 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1335 Number of LACNIC addresses announced to Internet: 171129216 Equivalent to 10 /8s, 51 /16s and 57 /24s Percentage of available LACNIC address space announced: 102.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12042 Total AfriNIC prefixes after maximum aggregation: 2835 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 12860 Unique aggregates announced from the AfriNIC address blocks: 4717 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 17.40 AfriNIC Region origin ASes announcing only one prefix: 212 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 55 Number of AfriNIC addresses announced to Internet: 59530240 Equivalent to 3 /8s, 140 /16s and 92 /24s Percentage of available AfriNIC address space announced: 59.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2944 11584 926 Korea Telecom 17974 2815 900 74 PT Telekomunikasi Indonesia 7545 2362 336 122 TPG Telecom Limited 4755 1914 413 192 TATA Communications formerly 9829 1641 1306 39 National Internet Backbone 4808 1414 2198 417 CNCGROUP IP network China169 9583 1320 105 541 Sify Limited 9498 1304 333 91 BHARTI Airtel Ltd. 9808 1292 6639 15 Guangdong Mobile Communicatio 7552 1232 1098 14 Viettel Corporation 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 2896 3688 51 BellSouth.net Inc. 22773 2891 2940 141 Cox Communications Inc. 18566 2045 379 181 MegaPath Corporation 7029 1932 1975 329 Windstream Communications Inc 20115 1803 1785 479 Charter Communications 4323 1634 1052 410 tw telecom holdings, inc. 6983 1492 867 249 ITC^Deltacom 30036 1477 309 626 Mediacom Communications Corp 701 1432 11258 716 MCI Communications Services, 22561 1307 408 237 CenturyTel Internet Holdings, 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 1822 296 348 TELLCOM ILETISIM HIZMETLERI A 20940 1493 580 1099 Akamai International B.V. 8402 1359 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1034 100 36 TOV "Bank-Inform" 8551 963 372 41 Bezeq International-Ltd 6849 834 356 26 JSC "Ukrtelecom" 12479 805 798 58 France Telecom Espana SA 6830 777 2334 432 Liberty Global Operations B.V 9198 668 346 28 JSC Kazakhtelecom 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 28573 3026 2311 114 NET Servi�os de Comunica��o S 10620 2990 484 249 Telmex Colombia S.A. 18881 1903 1036 22 Global Village Telecom 6147 1772 374 30 Telefonica del Peru S.A.A. 7303 1764 1175 250 Telecom Argentina S.A. 8151 1476 2999 434 Uninet S.A. de C.V. 6503 1109 434 59 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 27947 911 130 51 Telconet S.A 26615 902 2325 35 Tim Celular 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 8452 1300 958 13 TE-AS 24863 950 280 26 Link Egypt (Link.NET) 6713 678 760 38 Office National des Postes et 36992 347 824 27 ETISALAT MISR 24835 307 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 234 19 6 Data Telecom Service 15706 186 17 6 Sudatel (Sudan Telecom Co. Lt 12258 174 26 71 MWEB CONNECT (PROPRIETARY) LI 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 28573 3026 2311 114 NET Servi�os de Comunica��o S 10620 2990 484 249 Telmex Colombia S.A. 4766 2944 11584 926 Korea Telecom 6389 2896 3688 51 BellSouth.net Inc. 22773 2891 2940 141 Cox Communications Inc. 17974 2815 900 74 PT Telekomunikasi Indonesia 7545 2362 336 122 TPG Telecom Limited 18566 2045 379 181 MegaPath Corporation 7029 1932 1975 329 Windstream Communications Inc 4755 1914 413 192 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2896 2845 BellSouth.net Inc. 22773 2891 2750 Cox Communications Inc. 10620 2990 2741 Telmex Colombia S.A. 17974 2815 2741 PT Telekomunikasi Indonesia 7545 2362 2240 TPG Telecom Limited 4766 2944 2018 Korea Telecom 18881 1903 1881 Global Village Telecom 18566 2045 1864 MegaPath Corporation 6147 1772 1742 Telefonica del Peru S.A.A. 4755 1914 1722 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:12 /10:31 /11:90 /12:262 /13:504 /14:1003 /15:1714 /16:13037 /17:7095 /18:11802 /19:24588 /20:35312 /21:37686 /22:54782 /23:48002 /24:274515 /25:1091 /26:1056 /27:709 /28:16 /29:19 /30:10 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2124 2891 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1676 2896 BellSouth.net Inc. 6147 1337 1772 Telefonica del Peru S.A.A. 30036 1322 1477 Mediacom Communications Corp 6983 1185 1492 ITC^Deltacom 34984 1142 1822 TELLCOM ILETISIM HIZMETLERI A 7029 1138 1932 Windstream Communications Inc 11492 1125 1174 CABLE ONE, INC. 10620 1055 2990 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1348 2:663 3:3 4:17 5:1153 6:21 8:760 12:1848 13:4 14:1124 15:17 16:2 17:42 18:21 20:51 23:928 24:1751 27:1787 31:1407 32:41 33:2 34:5 36:157 37:1779 38:998 39:12 40:227 41:2979 42:271 43:423 44:17 45:76 46:2168 47:26 49:734 50:796 52:12 54:52 55:5 56:6 57:32 58:1211 59:640 60:432 61:1719 62:1272 63:1831 64:4404 65:2292 66:4192 67:2057 68:1047 69:3278 70:864 71:475 72:1977 74:2592 75:372 76:413 77:1608 78:925 79:764 80:1325 81:1249 82:793 83:757 84:730 85:1324 86:452 87:1157 88:475 89:1790 90:138 91:5759 92:758 93:1666 94:2086 95:1304 96:426 97:341 98:1100 99:48 100:66 101:727 103:5755 104:339 105:138 106:188 107:645 108:575 109:1987 110:1043 111:1379 112:714 113:900 114:782 115:1213 116:1129 117:991 118:1564 119:1364 120:436 121:973 122:2193 123:1636 124:1442 125:1509 128:612 129:348 130:362 131:872 132:430 133:165 134:325 135:78 136:306 137:292 138:379 139:195 140:223 141:405 142:596 143:420 144:498 145:111 146:685 147:554 148:968 149:379 150:498 151:710 152:471 153:240 154:356 155:561 156:376 157:332 158:277 159:940 160:325 161:604 162:1790 163:402 164:702 165:662 166:362 167:682 168:1119 169:119 170:1412 171:189 172:60 173:1622 174:704 175:615 176:1519 177:3568 178:2087 179:805 180:1765 181:1746 182:1647 183:558 184:717 185:2129 186:3006 187:1704 188:2155 189:1510 190:7890 191:769 192:7585 193:5522 194:4051 195:3586 196:1622 197:748 198:5152 199:5465 200:6466 201:2895 202:9120 203:9043 204:4577 205:2650 206:2975 207:2951 208:3921 209:3728 210:3293 211:1825 212:2363 213:2149 214:856 215:88 216:5616 217:1705 218:618 219:394 220:1371 221:692 222:483 223:601 End of report From ryan.landry at gmail.com Fri Oct 3 18:51:00 2014 From: ryan.landry at gmail.com (ryanL) Date: Fri, 3 Oct 2014 11:51:00 -0700 Subject: cogent update suppression, and routing loops In-Reply-To: References: Message-ID: circling back on this, i guess my case with cogent has been escalated to vp engineering, and i've had a few people reply on and off list citing the same problems. i encourage you to open up cases to help demonstrate further examples (ie: it's not just me!) thx everyone. ryan On Thu, Oct 2, 2014 at 9:03 AM, ryanL wrote: > hi. relatively new cogent customer. is what i've stated in my subject line > kinda standard fare with them? > > i've discovered that when i advertise a /24 from inside a larger /22 to > XO, (who peers with cogent), and then pull the /24 some time later, that > cogent holds onto the /24 and then bounces packets around in their network > a bunch of times for upwards of 8-10 minutes until they finally yank it. > this effectively blackholes traffic to my /24 for anyone that is using a > path thru cogent. > > example: http://ryry.foursquare.com/image/0e0K1K0t0W2M > > it's been a bit of a frustrating experience talking to their noc to > demonstrate it, but i'm able to duplicate it on demand. even pushing routes > using their communities to offload the circuit takes forever to propagate > even on their own looking-glasses. > > thx > > ryan > From swmike at swm.pp.se Fri Oct 3 19:03:45 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 3 Oct 2014 21:03:45 +0200 (CEST) Subject: large BCP38 compliance testing In-Reply-To: <20141003151745.GA24228@gsp.org> References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> <20141002225433.59C7720AF55D@rock.dv.isc.org> <20141003151745.GA24228@gsp.org> Message-ID: On Fri, 3 Oct 2014, Rich Kulawiec wrote: > The same thing applies here: persistent, systemic sources of large-scale > abuse via BCP-38 noncompliance are either: > > 1. Being operated by clueless, negligent, incompetent people > or > 2. Being operated by deliberately abusive people > > There are no other possibilities. (Note: "persistent, systemic". > Transient, isolated problems happen to everyone and are not what I'm > talking about here.) > > It's difficult to know which of those two are true via external > observation, but it's not *necessary* to know: the appropriate remedial > action remains the same in either case: stop giving them the means. So how do we detect these and make sure they feel pain for not doing the right thing. The CIDR report hasn't incurred pain as far as I know, so public shaming doesn't seem to work even in cases where we can detect people incurring hurt on others. So how do we work this? It obviously hasn't worked so far, what do we change to make this work? -- Mikael Abrahamsson email: swmike at swm.pp.se From ahebert at pubnix.net Fri Oct 3 19:20:58 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 03 Oct 2014 15:20:58 -0400 Subject: large BCP38 compliance testing In-Reply-To: References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> <20141002225433.59C7720AF55D@rock.dv.isc.org> <20141003151745.GA24228@gsp.org> Message-ID: <542EF71A.5020709@pubnix.net> Well (beware it is friday), On the 1st of January 2015: . Refuse every routes; . Start accepting only those passing some sort of BCP38 specs performed by some QSA =D; . ??? . Profit; On 10/03/14 15:03, Mikael Abrahamsson wrote: > On Fri, 3 Oct 2014, Rich Kulawiec wrote: > >> The same thing applies here: persistent, systemic sources of large-scale >> abuse via BCP-38 noncompliance are either: >> >> 1. Being operated by clueless, negligent, incompetent people >> or >> 2. Being operated by deliberately abusive people >> >> There are no other possibilities. (Note: "persistent, systemic". >> Transient, isolated problems happen to everyone and are not what I'm >> talking about here.) >> >> It's difficult to know which of those two are true via external >> observation, but it's not *necessary* to know: the appropriate remedial >> action remains the same in either case: stop giving them the means. > > So how do we detect these and make sure they feel pain for not doing > the right thing. The CIDR report hasn't incurred pain as far as I > know, so public shaming doesn't seem to work even in cases where we > can detect people incurring hurt on others. So how do we work this? It > obviously hasn't worked so far, what do we change to make this work? > From carlos at race.com Fri Oct 3 20:01:38 2014 From: carlos at race.com (Carlos Alcantar) Date: Fri, 3 Oct 2014 20:01:38 +0000 Subject: Equinix Sales In-Reply-To: References: Message-ID: coresite might be a good alternative if they are in the market you are trying to get space into. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 10/3/14, 7:33 AM, "Daniel Corbe" wrote: > >Equinix Sales seem impossible to reach. Should I just give up and go >through a sales agent or can someone from Equinix sales contact me >off-list? > > From dhubbard at dino.hostasaurus.com Fri Oct 3 20:06:55 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 3 Oct 2014 16:06:55 -0400 Subject: Marriott wifi blocking Message-ID: Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used "containment features of a Wi-Fi monitoring system" at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David From nick at flhsi.com Fri Oct 3 20:16:22 2014 From: nick at flhsi.com (Nick Olsen) Date: Fri, 3 Oct 2014 16:16:22 -0400 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <4673006a789d47f9a67f422a92609129@flhsi.com> Not sure the specific implementation. But I've heard of Rouge AP detection done in two ways. 1. Associate to the "Rouge" ap. Send a packet, See if it appears on your network, Shut the port off it appeared from. I think this is the cisco way? Not sure. This is automated of course. This method wouldn't work in this case. Because it wasn't connected to the hotels network 2. Your AP's detect the "Rouge" AP, They slam out a ton of "Deauth's" directed at the clients, As if they are the AP. Effectively telling the client to "disconnect". Side question for those smarter than I. How does WPA encryption play into this? Would a client associated to a WPA2 AP take a non-encrypted deauth appearing from the same BSSID? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Hubbard" Sent: Friday, October 03, 2014 4:11 PM To: "NANOG" Subject: Marriott wifi blocking Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used "containment features of a Wi-Fi monitoring system" at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David From telmnstr at 757.org Fri Oct 3 20:15:37 2014 From: telmnstr at 757.org (telmnstr at 757.org) Date: Fri, 3 Oct 2014 16:15:37 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: > I'm aware of how the illegal wifi blocking devices work, but > any idea what legal hardware they were using to effectively > keep their own wifi available but render everyone else's > inaccessible? Doesn't Cisco and other vendors offer "rouge AP squashing" features? - Ethan O'Toole From michael.holstein at csuohio.edu Fri Oct 3 20:16:09 2014 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 3 Oct 2014 20:16:09 +0000 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <1412367368703.67558@csuohio.edu> legality is questionable insofar as "this device must not cause harmful interference" of PartB but how it works is by sending DEAUTH packets with spoofed MAC addresses "rouge AP" response on Cisco/Aruba works like this. Regards, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of David Hubbard Sent: Friday, October 03, 2014 4:06 PM To: NANOG Subject: Marriott wifi blocking Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used "containment features of a Wi-Fi monitoring system" at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David From choprboy at dakotacom.net Fri Oct 3 20:17:02 2014 From: choprboy at dakotacom.net (Adrian) Date: Fri, 3 Oct 2014 13:17:02 -0700 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <201410031317.02163.choprboy@dakotacom.net> On Friday 03 October 2014 13:06:55 David Hubbard wrote: ... > I'm aware of how the illegal wifi blocking devices work, but > any idea what legal hardware they were using to effectively > keep their own wifi available but render everyone else's > inaccessible? > From other discussions, they were apparently continuously sending client deauth packets to any non-Marriott access points within range. Adrian From mianosm at gmail.com Fri Oct 3 20:16:37 2014 From: mianosm at gmail.com (Steven Miano) Date: Fri, 3 Oct 2014 16:16:37 -0400 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: There are IPS features in nearly all of the 'enterprise' level wireless products now: http://www.cisco.com/c/en/us/products/collateral/wireless/adaptive-wireless-ips-software/data_sheet_c78-501388.html http://www.aerohive.com/solutions/applications/secure.html Doing a search for WIPs - or browsing forums about poorly configured WIPS/Policies can show that the deauth storms can be quite turbulent. ~mianosm On Fri, Oct 3, 2014 at 4:06 PM, David Hubbard wrote: > Saw this article: > > http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ > > The interesting part: > > 'A federal investigation of the Gaylord Opryland Resort and > Convention Center in Nashville found that Marriott employees > had used "containment features of a Wi-Fi monitoring system" > at the hotel to prevent people from accessing their own > personal Wi-Fi networks.' > > I'm aware of how the illegal wifi blocking devices work, but > any idea what legal hardware they were using to effectively > keep their own wifi available but render everyone else's > inaccessible? > > David > From michael.holstein at csuohio.edu Fri Oct 3 20:18:02 2014 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 3 Oct 2014 20:18:02 +0000 Subject: Marriott wifi blocking In-Reply-To: <1412367368703.67558@csuohio.edu> References: , <1412367368703.67558@csuohio.edu> Message-ID: <1412367481866.97175@csuohio.edu> >but how it works is by sending DEAUTH packets with spoofed MAC addresses >"rouge AP" response on Cisco/Aruba works like this. DIY version if you want to try it out .. just download Kali/Backtrack or compile aircrack-ng http://www.aircrack-ng.org/doku.php?id=deauthentication Regards, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of David Hubbard Sent: Friday, October 03, 2014 4:06 PM To: NANOG Subject: Marriott wifi blocking Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used "containment features of a Wi-Fi monitoring system" at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David From Shane.Godmere at SHOPKO.COM Fri Oct 3 20:20:45 2014 From: Shane.Godmere at SHOPKO.COM (Godmere, Shane) Date: Fri, 3 Oct 2014 20:20:45 +0000 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Friday, October 03, 2014 3:07 PM To: NANOG Subject: Marriott wifi blocking Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used "containment features of a Wi-Fi monitoring system" at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David ------- David, All major WiFi players have some seek-and-destroy function to prevent rogues on/near their network. It is the responsibly of the IT folks to determine how aggressive these settings are, and to what needs deauth sent to clients. These can be very effective in dropping sessions from clients on unauthorized systems. The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. -- Opinions expressed in this email are mine and not that of my employer. Shane Allan Godmere From jtk at cymru.com Fri Oct 3 20:29:24 2014 From: jtk at cymru.com (John Kristoff) Date: Fri, 3 Oct 2014 15:29:24 -0500 Subject: Marriott wifi blocking In-Reply-To: <4673006a789d47f9a67f422a92609129@flhsi.com> References: <4673006a789d47f9a67f422a92609129@flhsi.com> Message-ID: <20141003152924.0f7ad6ef@localhost> On Fri, 3 Oct 2014 16:16:22 -0400 "Nick Olsen" wrote: > Not sure the specific implementation. But I've heard of Rouge AP > detection done in two ways. Relation discussion on this topic has come up from time to time. I believe the last time was in a thread that starts here and includes various methods of network-based rogue AP detection if you follow all the responses and links: One of my favorite ways long ago, not sure if this works reliably anymore, was to watch who was joining well known AP IP multicast groups commonly associated with different wireless gear, something you can easily do on routers (e.g. show ip igmp group _group_address_). There are also a number of well known OUIs associated with AP gear that are easily to monitor for in arp/bridge/cam tables. John From synack at live.com Fri Oct 3 20:31:31 2014 From: synack at live.com (Darin Herteen) Date: Fri, 3 Oct 2014 15:31:31 -0500 Subject: Marriott wifi blocking In-Reply-To: References: , Message-ID: Yes, I've tested it quite effectively using WLC 5508 and a AIR-CAP3502I-A-K9 > Date: Fri, 3 Oct 2014 16:15:37 -0400 > From: telmnstr at 757.org > CC: nanog at nanog.org > Subject: Re: Marriott wifi blocking > > > I'm aware of how the illegal wifi blocking devices work, but > > any idea what legal hardware they were using to effectively > > keep their own wifi available but render everyone else's > > inaccessible? > > Doesn't Cisco and other vendors offer "rouge AP squashing" features? > > - Ethan O'Toole > From owen at delong.com Fri Oct 3 20:31:32 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 13:31:32 -0700 Subject: Equinix Sales In-Reply-To: References: Message-ID: <67AB5FDB-5830-4C29-855A-C12194E9B567@delong.com> My experience with Core Site has been that their sales people are responsive, but their other areas not so much. What one would expect from a Telco-owned facility. Equinix, the sales people are less responsive, but at least when I open a ticket with them, it gets done pretty quickly in most cases. Owen On Oct 3, 2014, at 13:01 , Carlos Alcantar wrote: > coresite might be a good alternative if they are in the market you are > trying to get space into. > > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > > > On 10/3/14, 7:33 AM, "Daniel Corbe" wrote: > >> >> Equinix Sales seem impossible to reach. Should I just give up and go >> through a sales agent or can someone from Equinix sales contact me >> off-list? >> >> From jfbeam at gmail.com Fri Oct 3 21:04:45 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 03 Oct 2014 17:04:45 -0400 Subject: Marriott wifi blocking In-Reply-To: <4673006a789d47f9a67f422a92609129@flhsi.com> References: <4673006a789d47f9a67f422a92609129@flhsi.com> Message-ID: On Fri, 03 Oct 2014 16:16:22 -0400, Nick Olsen wrote: > Side question for those smarter than I. How does WPA encryption play > into this? Would a client associated to a WPA2 AP take a non-encrypted > deauth appearing from the same BSSID? It doesn't. The DEAUTH management frame is not encrypted and carries no authentication. The 802.11 spec only requires a reason code be provided. --Ricky From ktims at stargate.ca Fri Oct 3 21:23:46 2014 From: ktims at stargate.ca (Keenan Tims) Date: Fri, 03 Oct 2014 14:23:46 -0700 Subject: Marriott wifi blocking In-Reply-To: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> Message-ID: <542F13E2.7060407@stargate.ca> > The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. I can't imagine that any 'AP-squashing' packets are ever authorized, outside of a lab. The wireless spectrum is shared by all, regardless of physical locality. Because it's your building doesn't mean you own the spectrum. My reading of this is that these features are illegal, period. Rogue AP detection is one thing, and disabling them via network or "administrative" (ie. eject the guest) means would be fine, but interfering with the wireless is not acceptable per the FCC regulations. Seems like common sense to me. If the FCC considers this 'interference', which it apparently does, then devices MUST NOT intentionally interfere. K From cidr-report at potaroo.net Fri Oct 3 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Oct 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201410032200.s93M01Mn003256@wattle.apnic.net> This report has been generated at Fri Oct 3 21:14:05 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-09-14 517584 286968 27-09-14 517645 286987 28-09-14 517067 287333 29-09-14 517697 287127 30-09-14 517392 287790 01-10-14 518035 287253 02-10-14 518063 287399 03-10-14 518176 287885 AS Summary 48431 Number of ASes in routing system 19548 Number of ASes announcing only one prefix 3026 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120100352 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 03Oct14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 518309 287887 230422 44.5% All ASes AS28573 3026 133 2893 95.6% NET Servi�os de Comunica��o S.A.,BR AS6389 2895 69 2826 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2815 80 2735 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2894 161 2733 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4766 2945 1207 1738 59.0% KIXS-AS-KR Korea Telecom,KR AS6147 1782 166 1616 90.7% Telefonica del Peru S.A.A.,PE AS7303 1769 300 1469 83.0% Telecom Argentina S.A.,AR AS18881 1903 552 1351 71.0% Global Village Telecom,BR AS8402 1335 25 1310 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1912 651 1261 66.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1804 554 1250 69.3% CHARTER-NET-HKY-NC - Charter Communications,US AS9808 1292 56 1236 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4323 1644 413 1231 74.9% TWTC - tw telecom holdings, inc.,US AS7545 2377 1158 1219 51.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1263 60 1203 95.2% VIETEL-AS-AP Viettel Corporation,VN AS9498 1306 109 1197 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS10620 2992 1805 1187 39.7% Telmex Colombia S.A.,CO AS18566 2044 866 1178 57.6% MEGAPATH5-US - MegaPath Corporation,US AS22561 1306 306 1000 76.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7029 2038 1051 987 48.4% WINDSTREAM - Windstream Communications Inc,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS6983 1492 629 863 57.8% ITCDELTA - Earthlink, Inc.,US AS4788 1071 244 827 77.2% TMNET-AS-AP TM Net, Internet Service Provider,MY AS38285 956 132 824 86.2% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1173 354 819 69.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4780 1042 266 776 74.5% SEEDNET Digital United Inc.,TW AS26615 902 135 767 85.0% Tim Celular S.A.,BR AS18101 957 197 760 79.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1484 737 747 50.3% Uninet S.A. de C.V.,MX AS17908 838 92 746 89.0% TCISL Tata Communications,IN Total 52256 12591 39665 75.9% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.220.173.0/24 AS30058 FDCSERVERS - FDCservers.net,US 91.228.160.0/24 AS19979 DEPO40-AS Trusov Ilya Igorevych,RU 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.157.184.0/22 AS12714 TI-AS Net By Net Holding LLC,RU 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.36.0/22 AS24295 AS-PNAPOSK Internap Japan Co.,Ltd.,JP 104.193.252.0/22 AS14576 HOSTING-SOLUTIONS - Hosting Solution Ltd.,US 104.206.0.0/16 AS30693 SERVERHUB-PHOENIX - Eonix Corporation,US 104.218.48.0/21 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.103.32.0/24 AS23861 117.103.33.0/24 AS23861 117.103.34.0/24 AS23861 117.103.35.0/24 AS23861 117.103.36.0/24 AS23861 117.103.37.0/24 AS23861 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.210.240.0/24 AS17246 -Reserved AS-,ZZ 162.210.241.0/24 AS17246 -Reserved AS-,ZZ 162.210.244.0/24 AS17246 -Reserved AS-,ZZ 162.210.245.0/24 AS17246 -Reserved AS-,ZZ 162.210.246.0/24 AS17246 -Reserved AS-,ZZ 162.210.247.0/24 AS17246 -Reserved AS-,ZZ 162.244.140.0/24 AS17246 -Reserved AS-,ZZ 162.244.141.0/24 AS17246 -Reserved AS-,ZZ 162.244.142.0/24 AS17246 -Reserved AS-,ZZ 162.244.143.0/24 AS17246 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.24.0/24 AS55503 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 cidr-report at potaroo.net Fri Oct 3 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Oct 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201410032200.s93M02od003269@wattle.apnic.net> BGP Update Report Interval: 25-Sep-14 -to- 02-Oct-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 583990 11.3% 421.3 -- SIFY-AS-IN Sify Limited,IN 2 - AS9829 198729 3.8% 174.8 -- BSNL-NIB National Internet Backbone,IN 3 - AS23752 196055 3.8% 1519.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS24193 177229 3.4% 798.3 -- SIFY-IN Sify Limited Service Provider India,IN 5 - AS3816 104096 2.0% 178.2 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 6 - AS45816 100073 1.9% 3127.3 -- ISHK-AP I-Services Network Solution Limited,HK 7 - AS3633 98012 1.9% 276.9 -- PROVINCE-OF-BRITISH-COLUMBIA - Province of British Columbia,CA 8 - AS8402 59612 1.1% 97.6 -- CORBINA-AS OJSC "Vimpelcom",RU 9 - AS45899 58284 1.1% 121.9 -- VNPT-AS-VN VNPT Corp,VN 10 - AS13682 52871 1.0% 5874.6 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 11 - AS13188 49032 0.9% 52.2 -- BANKINFORM-AS TOV "Bank-Inform",UA 12 - AS7552 43513 0.8% 34.5 -- VIETEL-AS-AP Viettel Corporation,VN 13 - AS7029 42754 0.8% 7.1 -- WINDSTREAM - Windstream Communications Inc,US 14 - AS38197 41401 0.8% 67.2 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 15 - AS1659 38784 0.8% 153.9 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 16 - AS2119 35869 0.7% 167.6 -- TELENOR-NEXTEL Telenor Norge AS,NO 17 - AS28573 34162 0.7% 20.9 -- NET Servi�os de Comunica��o S.A.,BR 18 - AS17552 27921 0.5% 362.6 -- TRUE-AS-AP True Internet Co.,Ltd.,TH 19 - AS47331 21546 0.4% 7.3 -- TTNET TTNet A.S.,TR 20 - AS23342 21142 0.4% 528.5 -- UNITEDLAYER - Unitedlayer, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS25003 19569 0.4% 9784.5 -- INTERNET_BINAT Internet Binat Ltd,IL 2 - AS62318 6518 0.1% 6518.0 -- BIMEH-MA-AS Bimeh Ma,IR 3 - AS13682 52871 1.0% 5874.6 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 4 - AS2 4673 0.1% 661.0 -- UDEL-DCN - University of Delaware,US 5 - AS32336 4228 0.1% 4228.0 -- IPASS-2 - iPass Incorporated,US 6 - AS51888 3429 0.1% 3429.0 -- PILOTSYSTEMS-AS Pilot Systems consulting SARL,FR 7 - AS45816 100073 1.9% 3127.3 -- ISHK-AP I-Services Network Solution Limited,HK 8 - AS47680 2781 0.1% 2781.0 -- NHCS EOBO Limited,IE 9 - AS18135 12510 0.2% 2502.0 -- BTV BTV Cable television,JP 10 - AS6629 9646 0.2% 2411.5 -- NOAA-AS - NOAA,US 11 - AS41762 2180 0.0% 2180.0 -- SEVNET PE Logvinov Vladimir Vladimirovich,UA 12 - AS60599 2003 0.0% 2003.0 -- WEBKOMPAS-AS Emelyanov Valentin Petrovich,RU 13 - AS30944 1758 0.0% 1758.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 14 - AS35093 3325 0.1% 1662.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 15 - AS27390 1655 0.0% 1655.0 -- ALGAS - Fred Alger & Co Inc.,US 16 - AS62174 1597 0.0% 1597.0 -- INTERPAN-AS INTERPAN LTD.,BG 17 - AS6468 3177 0.1% 1588.5 -- EASYLINK-AS6468 - Easylink Services Corporation,US 18 - AS3 1546 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 19 - AS23752 196055 3.8% 1519.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 20 - AS57201 1502 0.0% 1502.0 -- EDF-AS Estonian Defence Forces,EE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 98144 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 96252 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 64.29.130.0/24 21064 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 4 - 192.115.44.0/22 19568 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 5 - 41.221.20.0/24 13637 0.2% AS36947 -- ALGTEL-AS,DZ 6 - 42.83.48.0/20 12494 0.2% AS18135 -- BTV BTV Cable television,JP 7 - 200.34.149.0/24 10487 0.2% AS8151 -- Uninet S.A. de C.V.,MX 8 - 200.119.160.0/19 9888 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 9 - 190.143.240.0/20 9872 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 10 - 192.58.232.0/24 9640 0.2% AS6629 -- NOAA-AS - NOAA,US 11 - 190.143.224.0/20 8805 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 12 - 190.143.192.0/19 8800 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 13 - 200.119.152.0/21 8659 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 14 - 85.217.138.0/23 7629 0.1% AS24964 -- EVO-LTD MOBILTEL EAD,BG 15 - 200.119.150.0/23 6828 0.1% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 16 - 5.160.30.0/24 6518 0.1% AS62318 -- BIMEH-MA-AS Bimeh Ma,IR 17 - 163.15.192.0/24 6268 0.1% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 18 - 163.15.185.0/24 6268 0.1% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 19 - 120.118.64.0/19 6266 0.1% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 20 - 203.64.238.0/24 6266 0.1% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 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 jschiel at flowtools.net Fri Oct 3 22:01:21 2014 From: jschiel at flowtools.net (John Schiel) Date: Fri, 03 Oct 2014 16:01:21 -0600 Subject: Marriott wifi blocking In-Reply-To: <542F13E2.7060407@stargate.ca> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> Message-ID: <542F1CB1.4030309@flowtools.net> On 10/03/2014 03:23 PM, Keenan Tims wrote: >> The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. > I can't imagine that any 'AP-squashing' packets are ever authorized, > outside of a lab. The wireless spectrum is shared by all, regardless of > physical locality. Because it's your building doesn't mean you own the > spectrum. +1 > > My reading of this is that these features are illegal, period. Rogue AP > detection is one thing, and disabling them via network or > "administrative" (ie. eject the guest) means would be fine, but > interfering with the wireless is not acceptable per the FCC regulations. > > Seems like common sense to me. If the FCC considers this 'interference', > which it apparently does, then devices MUST NOT intentionally interfere. I would expect interfering for defensive purposes **only** would be acceptable. --John > > K From hugo at slabnet.com Fri Oct 3 22:26:27 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 15:26:27 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F1CB1.4030309@flowtools.net> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> Message-ID: <20141003222627.GA1424@bamboo.slabnet.com> On Fri 2014-Oct-03 16:01:21 -0600, John Schiel wrote: > >On 10/03/2014 03:23 PM, Keenan Tims wrote: >>>The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >>I can't imagine that any 'AP-squashing' packets are ever authorized, >>outside of a lab. The wireless spectrum is shared by all, regardless of >>physical locality. Because it's your building doesn't mean you own the >>spectrum. > >+1 > >> >>My reading of this is that these features are illegal, period. Rogue AP >>detection is one thing, and disabling them via network or >>"administrative" (ie. eject the guest) means would be fine, but >>interfering with the wireless is not acceptable per the FCC regulations. >> >>Seems like common sense to me. If the FCC considers this 'interference', >>which it apparently does, then devices MUST NOT intentionally interfere. > >I would expect interfering for defensive purposes **only** would be >acceptable. What constitutes "defensive purposes"? > >--John > >> >>K > -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From mvn at ucla.edu Fri Oct 3 22:34:14 2014 From: mvn at ucla.edu (Michael Van Norman) Date: Fri, 03 Oct 2014 15:34:14 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141003222627.GA1424@bamboo.slabnet.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> <20141003222627.GA1424@bamboo.slabnet.com> Message-ID: >>>My reading of this is that these features are illegal, period. Rogue AP >>>detection is one thing, and disabling them via network or >>>"administrative" (ie. eject the guest) means would be fine, but >>>interfering with the wireless is not acceptable per the FCC regulations. >>> >>>Seems like common sense to me. If the FCC considers this 'interference', >>>which it apparently does, then devices MUST NOT intentionally interfere. >> >>I would expect interfering for defensive purposes **only** would be >>acceptable. > >What constitutes "defensive purposes"? Since this is unlicensed spectrum, I don't think there is anything one has a right to defend :) /Mike From lyle at lcrcomputer.net Fri Oct 3 22:44:07 2014 From: lyle at lcrcomputer.net (Lyle Giese) Date: Fri, 03 Oct 2014 17:44:07 -0500 Subject: Marriott wifi blocking In-Reply-To: References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> <20141003222627.GA1424@bamboo.slabnet.com> Message-ID: <542F26B7.3090002@lcrcomputer.net> On 10/03/14 17:34, Michael Van Norman wrote: >>>> My reading of this is that these features are illegal, period. Rogue AP >>>> detection is one thing, and disabling them via network or >>>> "administrative" (ie. eject the guest) means would be fine, but >>>> interfering with the wireless is not acceptable per the FCC regulations. >>>> >>>> Seems like common sense to me. If the FCC considers this 'interference', >>>> which it apparently does, then devices MUST NOT intentionally interfere. >>> I would expect interfering for defensive purposes **only** would be >>> acceptable. >> What constitutes "defensive purposes"? > Since this is unlicensed spectrum, I don't think there is anything one has > a right to defend :) > > /Mike > > If you charge for access and one person pays and sets up a rogue AP offering free WiFi to anyone in range. I can see a defensive angle there. Lyle Giese LCR Computer Services, Inc. From mvn at ucla.edu Fri Oct 3 22:54:22 2014 From: mvn at ucla.edu (Michael Van Norman) Date: Fri, 03 Oct 2014 15:54:22 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F26B7.3090002@lcrcomputer.net> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> <20141003222627.GA1424@bamboo.slabnet.com> <542F26B7.3090002@lcrcomputer.net> Message-ID: On 10/3/14 3:44 PM, "Lyle Giese" wrote: > >On 10/03/14 17:34, Michael Van Norman wrote: >>>>> My reading of this is that these features are illegal, period. Rogue >>>>>AP >>>>> detection is one thing, and disabling them via network or >>>>> "administrative" (ie. eject the guest) means would be fine, but >>>>> interfering with the wireless is not acceptable per the FCC >>>>>regulations. >>>>> >>>>> Seems like common sense to me. If the FCC considers this >>>>>'interference', >>>>> which it apparently does, then devices MUST NOT intentionally >>>>>interfere. >>>> I would expect interfering for defensive purposes **only** would be >>>> acceptable. >>> What constitutes "defensive purposes"? >> Since this is unlicensed spectrum, I don't think there is anything one >>has >> a right to defend :) >> >> /Mike >> >> >If you charge for access and one person pays and sets up a rogue AP >offering free WiFi to anyone in range. I can see a defensive angle there. > >Lyle Giese >LCR Computer Services, Inc. In that case turn off the offenders access. No FCC violation doing that. In any case, that was not what was happening here. /Mike From web at typo.org Fri Oct 3 23:12:28 2014 From: web at typo.org (Wayne E Bouchard) Date: Fri, 3 Oct 2014 16:12:28 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F13E2.7060407@stargate.ca> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> Message-ID: <20141003231228.GA79197@wakko.typo.org> On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: > > The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. > > I can't imagine that any 'AP-squashing' packets are ever authorized, > outside of a lab. The wireless spectrum is shared by all, regardless of > physical locality. Because it's your building doesn't mean you own the > spectrum. > I think that depends on the terms of your lease agreement. Could not a hotel or conference center operate reserve the right to employ active devices to disable any unauthorized wireless systems? Perhaps because they want to charge to provide that service, because they don't want errant signals leaking from their building, a rogue device could be considered an intruder and represent a risk to the network, or because they don't want someone setting up a system that would interfere with their wireless gear and take down other clients who are on premesis... Would not such an active device be quite appropriate there? -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From joelja at bogus.com Fri Oct 3 23:15:47 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 03 Oct 2014 19:15:47 -0400 Subject: Marriott wifi blocking In-Reply-To: <542F1CB1.4030309@flowtools.net> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> Message-ID: <542F2E23.2040404@bogus.com> On 10/3/14 6:01 PM, John Schiel wrote: > > On 10/03/2014 03:23 PM, Keenan Tims wrote: >>> The question here is what is authorized and what is not. Was this to >>> protect their network from rogues, or protect revenue from captive >>> customers. >> I can't imagine that any 'AP-squashing' packets are ever authorized, >> outside of a lab. The wireless spectrum is shared by all, regardless of >> physical locality. Because it's your building doesn't mean you own the >> spectrum. > > +1 > >> >> My reading of this is that these features are illegal, period. Rogue AP >> detection is one thing, and disabling them via network or >> "administrative" (ie. eject the guest) means would be fine, but >> interfering with the wireless is not acceptable per the FCC regulations. >> >> Seems like common sense to me. If the FCC considers this 'interference', >> which it apparently does, then devices MUST NOT intentionally interfere. > > I would expect interfering for defensive purposes **only** would be > acceptable. if you have a device licensed under fcc part 15 it may not cause harmful interference to other users of the spectrum. > --John > >> >> K > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Fri Oct 3 23:18:02 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 03 Oct 2014 19:18:02 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141003231228.GA79197@wakko.typo.org> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> Message-ID: <542F2EAA.6020406@bogus.com> On 10/3/14 7:12 PM, Wayne E Bouchard wrote: > On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >>> The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >> >> I can't imagine that any 'AP-squashing' packets are ever authorized, >> outside of a lab. The wireless spectrum is shared by all, regardless of >> physical locality. Because it's your building doesn't mean you own the >> spectrum. >> > > I think that depends on the terms of your lease agreement. Could not > a hotel or conference center operate reserve the right to employ > active devices to disable any unauthorized wireless systems? Perhaps > because they want to charge to provide that service, because they > don't want errant signals leaking from their building, a rogue device > could be considered an intruder and represent a risk to the network, > or because they don't want someone setting up a system that would > interfere with their wireless gear and take down other clients who are > on premesis... > > Would not such an active device be quite appropriate there? http://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet63/oet63rev.pdf ... The FCC rules are designed to control the marketing of low-power transmitters and, to a lesser extent, their use. If the operation of a non-compliant transmitter causes interference to authorized radio communications, the user should stop operating the transmitter or correct the problem causing the interference. However, the person (or company) that sold this non-compliant transmitter to the user has violated the FCC marketing rules in Part 2 as well as federal law. The act of selling or leasing, offering to sell or lease, or importing a low-power transmitter that has not gone through the appropriate FCC equipment authorization procedure is a violation of the Commission's rules and federal law. ... > > -Wayne > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From jra at baylink.com Fri Oct 3 23:36:25 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 3 Oct 2014 19:36:25 -0400 (EDT) Subject: large BCP38 compliance testing In-Reply-To: <542D4239.1020203@pubnix.net> Message-ID: <23040140.4187.1412379385016.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alain Hebert" > PS: About that uRPF Convo, we could dump all that knowledges into > lets say... some comprehensive wiki page maybe =D That way when the > topic arise we could just link to it. Gee, Alain... where would people find a wiki like that? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From owen at delong.com Fri Oct 3 23:49:49 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 16:49:49 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141003231228.GA79197@wakko.typo.org> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> Message-ID: On Oct 3, 2014, at 16:12 , Wayne E Bouchard wrote: > On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >>> The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >> >> I can't imagine that any 'AP-squashing' packets are ever authorized, >> outside of a lab. The wireless spectrum is shared by all, regardless of >> physical locality. Because it's your building doesn't mean you own the >> spectrum. >> > > I think that depends on the terms of your lease agreement. Could not > a hotel or conference center operate reserve the right to employ > active devices to disable any unauthorized wireless systems? Perhaps > because they want to charge to provide that service, because they > don't want errant signals leaking from their building, a rogue device > could be considered an intruder and represent a risk to the network, > or because they don't want someone setting up a system that would > interfere with their wireless gear and take down other clients who are > on premesis... > > Would not such an active device be quite appropriate there? You may consider it appropriate from a financial or moral perspective, but it is absolutely wrong under the communications act of 1934 as amended. The following is an oversimplification and IANAL, but generally: You are _NOT_ allowed to intentionally cause harmful interference with a signal for any reason. If you are the primary user on a frequency, you are allowed to conduct your normal operations without undue concern for other users of the same spectrum, but you are not allowed to deliberately interfere with any secondary user just for the sake of interfering with them. The kind of active devices being discussed and the activities of the hotel in question appear to have run well afoul of these regulations. As someone else said, owning the property does not constitute ownership of the airwaves within the boundaries of the property, at least in the US (and I suspect in most if not all ITU countries). Owen From jra at baylink.com Fri Oct 3 23:54:12 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 3 Oct 2014 19:54:12 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: Message-ID: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ricky Beam" > It doesn't. The DEAUTH management frame is not encrypted and carries no > authentication. The 802.11 spec only requires a reason code be > provided. What's the code for E_GREEDY? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From eyeronic.design at gmail.com Sat Oct 4 00:15:14 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 3 Oct 2014 17:15:14 -0700 Subject: Marriott wifi blocking In-Reply-To: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> Message-ID: So does that mean the anti-rogue AP technologies by the various vendors are illegal if used in the US? On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Ricky Beam" > >> It doesn't. The DEAUTH management frame is not encrypted and carries no >> authentication. The 802.11 spec only requires a reason code be >> provided. > > What's the code for E_GREEDY? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From d3e3e3 at gmail.com Sat Oct 4 00:19:43 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 3 Oct 2014 20:19:43 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141003231228.GA79197@wakko.typo.org> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> Message-ID: IANAL but no, I think it most certainly does not, at least in the USA, depend on the terms of your *lease* agreement. In particular, I refer you to http://apps.fcc.gov/ecfs/document/view;?id=6518608517 where in the US Federal Communications Commission (FCC) specifically voided terms restricting Wi-Fi in space leased from the Massachusetts Port Authority at Boston airport as in violation of the OTARD (Over The Air Reception Device) FCC rules. This probably doesn't apply if you are a mere licensee but if you are a leaseholder, including being a tenant-in-possession, as you are if you rent a hotel room, I think they do apply. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Fri, Oct 3, 2014 at 7:12 PM, Wayne E Bouchard wrote: > On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >> > The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >> >> I can't imagine that any 'AP-squashing' packets are ever authorized, >> outside of a lab. The wireless spectrum is shared by all, regardless of >> physical locality. Because it's your building doesn't mean you own the >> spectrum. >> > > I think that depends on the terms of your lease agreement. Could not > a hotel or conference center operate reserve the right to employ > active devices to disable any unauthorized wireless systems? Perhaps > because they want to charge to provide that service, because they > don't want errant signals leaking from their building, a rogue device > could be considered an intruder and represent a risk to the network, > or because they don't want someone setting up a system that would > interfere with their wireless gear and take down other clients who are > on premesis... > > Would not such an active device be quite appropriate there? > > -Wayne > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ From jra at baylink.com Sat Oct 4 00:21:48 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 3 Oct 2014 20:21:48 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: Message-ID: <22149532.4203.1412382108798.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Oct 3, 2014, at 16:12 , Wayne E Bouchard wrote: > > Would not such an active device be quite appropriate there? > > You may consider it appropriate from a financial or moral perspective, > but it is absolutely wrong under the communications act of 1934 as > amended. > > The following is an oversimplification and IANAL, but generally: > > You are _NOT_ allowed to intentionally cause harmful interference with > a signal for any reason. If you are the primary user on a frequency, > you are allowed to conduct your normal operations without undue > concern for other users of the same spectrum, but you are not allowed > to deliberately interfere with any secondary user just for the sake of > interfering with them. > > The kind of active devices being discussed and the activities of the > hotel in question appear to have run well afoul of these regulations. Well, this will certainly have interesting implications on providing wireless service on business premises, won't it? Are Cisco et alia accessories-before? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mvn at ucla.edu Sat Oct 4 00:21:08 2014 From: mvn at ucla.edu (Michael Van Norman) Date: Fri, 03 Oct 2014 17:21:08 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> Message-ID: IANAL, but I believe they are. State laws may also apply (e.g. California Code - Section 502). In California, it is illegal to "knowingly and without permission disrupts or causes the disruption of computer services or denies or causes the denial of computer services to an authorized user of a computer, computer system, or computer network." Blocking access to somebody's personal hot spot most likely qualifies. /Mike On 10/3/14 5:15 PM, "Mike Hale" wrote: >So does that mean the anti-rogue AP technologies by the various >vendors are illegal if used in the US? > >On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Ricky Beam" >> >>> It doesn't. The DEAUTH management frame is not encrypted and carries no >>> authentication. The 802.11 spec only requires a reason code be >>> provided. >> >> What's the code for E_GREEDY? >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >>jra at baylink.com >> Designer The Things I Think >>RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land >>Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >>647 1274 > > > >-- >09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From larrysheldon at cox.net Sat Oct 4 01:31:56 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 03 Oct 2014 20:31:56 -0500 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <542F4E0C.4030203@cox.net> On 10/3/2014 15:16, Nick Olsen wrote: > Not sure the specific implementation. But I've heard of Rouge AP detection > done in two ways. Forgive me, I have been out of active large scale network administration for a number of years and have really lost touch. What it is about red-colored APs that is offensive? I have never seen one. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From hugo at slabnet.com Sat Oct 4 02:25:22 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 19:25:22 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> Message-ID: <20141004022522.GB1424@bamboo.slabnet.com> On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman wrote: >IANAL, but I believe they are. State laws may also apply (e.g. California >Code - Section 502). In California, it is illegal to "knowingly and >without permission disrupts or causes the disruption of computer services >or denies or causes the denial of computer services to an authorized user >of a computer, computer system, or computer network." Blocking access to >somebody's personal hot spot most likely qualifies. My guess would be that the hotel or other organizations using the blocking tech would probably just say the users/admin of the rogue APs are not authorized users as setting up said AP would probably be in contravention of the AUP of the hotel/org network. > >/Mike > > -- Hugo >On 10/3/14 5:15 PM, "Mike Hale" wrote: > >>So does that mean the anti-rogue AP technologies by the various >>vendors are illegal if used in the US? >> >>On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Ricky Beam" >>> >>>> It doesn't. The DEAUTH management frame is not encrypted and carries no >>>> authentication. The 802.11 spec only requires a reason code be >>>> provided. >>> >>> What's the code for E_GREEDY? >>> >>> Cheers, >>> -- jra >>> -- >>> Jay R. Ashworth Baylink >>>jra at baylink.com >>> Designer The Things I Think >>>RFC 2100 >>> Ashworth & Associates http://www.bcp38.info 2000 Land >>>Rover DII >>> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >>>647 1274 >> >> >> >>-- >>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jra at baylink.com Sat Oct 4 02:27:06 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 03 Oct 2014 22:27:06 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141004022522.GB1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: Except that this is the difference between what happens at a Marriott and what would happen at a business that was running rogue AP detection. In the business the portable AP would be trying to look like the network that the company operated so as to siphon off legitimate users. In a hotel the portable AP would be trying to create a different, separate network. And so your thesis does not hold. I think this is the distinction we need. Because it's clear that the business thing should be able to happen and the hotel thing should On October 3, 2014 10:25:22 PM EDT, Hugo Slabbert wrote: >On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >wrote: > >>IANAL, but I believe they are. State laws may also apply (e.g. >California >>Code - Section 502). In California, it is illegal to "knowingly and >>without permission disrupts or causes the disruption of computer >services >>or denies or causes the denial of computer services to an authorized >user >>of a computer, computer system, or computer network." Blocking access >to >>somebody's personal hot spot most likely qualifies. > >My guess would be that the hotel or other organizations using the >blocking tech would probably just say the users/admin of the rogue APs >are not authorized users as setting up said AP would probably be in >contravention of the AUP of the hotel/org network. > >> >>/Mike >> >> > >-- >Hugo > >>On 10/3/14 5:15 PM, "Mike Hale" wrote: >> >>>So does that mean the anti-rogue AP technologies by the various >>>vendors are illegal if used in the US? >>> >>>On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >>>> ----- Original Message ----- >>>>> From: "Ricky Beam" >>>> >>>>> It doesn't. The DEAUTH management frame is not encrypted and >carries no >>>>> authentication. The 802.11 spec only requires a reason code be >>>>> provided. >>>> >>>> What's the code for E_GREEDY? >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink >>>>jra at baylink.com >>>> Designer The Things I Think >>>>RFC 2100 >>>> Ashworth & Associates http://www.bcp38.info 2000 >Land >>>>Rover DII >>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 >727 >>>>647 1274 >>> >>> >>> >>>-- >>>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From hugo at slabnet.com Sat Oct 4 02:42:33 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 19:42:33 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> Message-ID: <20141004024233.GC1424@bamboo.slabnet.com> On Fri 2014-Oct-03 16:49:49 -0700, Owen DeLong wrote: > >On Oct 3, 2014, at 16:12 , Wayne E Bouchard wrote: > >> On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >>>> The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >>> >>> I can't imagine that any 'AP-squashing' packets are ever authorized, >>> outside of a lab. The wireless spectrum is shared by all, regardless of >>> physical locality. Because it's your building doesn't mean you own the >>> spectrum. >>> >> >> I think that depends on the terms of your lease agreement. Could not >> a hotel or conference center operate reserve the right to employ >> active devices to disable any unauthorized wireless systems? Perhaps >> because they want to charge to provide that service, because they >> don't want errant signals leaking from their building, a rogue device >> could be considered an intruder and represent a risk to the network, >> or because they don't want someone setting up a system that would >> interfere with their wireless gear and take down other clients who are >> on premesis... >> >> Would not such an active device be quite appropriate there? > >You may consider it appropriate from a financial or moral perspective, but it is absolutely wrong under the communications act of 1934 as amended. > >The following is an oversimplification and IANAL, but generally: > >You are _NOT_ allowed to intentionally cause harmful interference with a signal for any reason. If you are the primary user on a frequency, you are allowed to conduct your normal operations without undue concern for other users of the same spectrum, but you are not allowed to deliberately interfere with any secondary user just for the sake of interfering with them. > >The kind of active devices being discussed and the activities of the hotel in question appear to have run well afoul of these regulations. > >As someone else said, owning the property does not constitute ownership of the airwaves within the boundaries of the property, at least in the US (and I suspect in most if not all ITU countries). > >Owen > Serious question: do the FCC regulations on RF spectrum interference extend beyond layer 1? I would assume that blasting a bunch of RF noise would be pretty obviously out of bounds, but my understanding is that the mechanisms described for rogue AP squashing operate at L2. The *effect* is to render the wireless medium pretty much useless for its intended purpose, but that's accomplished by the use (abuse?) of higher layer control mechanisms. I'm not condoning this, but do the FCC regulations RF interference apply? Do they have authority above L1 in this case? -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From mvn at ucla.edu Sat Oct 4 02:45:57 2014 From: mvn at ucla.edu (Michael Van Norman) Date: Fri, 03 Oct 2014 19:45:57 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004022522.GB1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: >On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >wrote: > >>IANAL, but I believe they are. State laws may also apply (e.g. >>California >>Code - Section 502). In California, it is illegal to "knowingly and >>without permission disrupts or causes the disruption of computer services >>or denies or causes the denial of computer services to an authorized user >>of a computer, computer system, or computer network." Blocking access to >>somebody's personal hot spot most likely qualifies. > >My guess would be that the hotel or other organizations using the >blocking tech would probably just say the users/admin of the rogue APs >are not authorized users as setting up said AP would probably be in >contravention of the AUP of the hotel/org network. They can say anything they want, it does not make it legal. There's no such thing as a "rogue" AP in this context. I can run an access point almost anywhere I want (there are limits established by the FCC in some areas) and it does not matter who owns the land underneath. They have no authority to decide whether or not my access point is "authorized." They can certainly refuse to connect me to their wired network; and they can disconnect me if they decide I am making inappropriate use of their network -- but they have no legal authority to interfere with my wireless transmissions on my own network (be it my personal hotspot, WiFi router, etc.). FWIW, the same is true in almost all corporate environments as well. /Mike From mvn at ucla.edu Sat Oct 4 02:48:23 2014 From: mvn at ucla.edu (Michael Van Norman) Date: Fri, 03 Oct 2014 19:48:23 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004024233.GC1424@bamboo.slabnet.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> <20141004024233.GC1424@bamboo.slabnet.com> Message-ID: One of the reasons I pointed to the California law is that it covers above L1 even if FCC authority does not. The state law also provides for criminal penalties. I do not know if other states have similar laws. /Mike On 10/3/14 7:42 PM, "Hugo Slabbert" wrote: >On Fri 2014-Oct-03 16:49:49 -0700, Owen DeLong wrote: > >> >>On Oct 3, 2014, at 16:12 , Wayne E Bouchard wrote: >> >>> On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >>>>> The question here is what is authorized and what is not. Was this >>>>>to protect their network from rogues, or protect revenue from captive >>>>>customers. >>>> >>>> I can't imagine that any 'AP-squashing' packets are ever authorized, >>>> outside of a lab. The wireless spectrum is shared by all, regardless >>>>of >>>> physical locality. Because it's your building doesn't mean you own the >>>> spectrum. >>>> >>> >>> I think that depends on the terms of your lease agreement. Could not >>> a hotel or conference center operate reserve the right to employ >>> active devices to disable any unauthorized wireless systems? Perhaps >>> because they want to charge to provide that service, because they >>> don't want errant signals leaking from their building, a rogue device >>> could be considered an intruder and represent a risk to the network, >>> or because they don't want someone setting up a system that would >>> interfere with their wireless gear and take down other clients who are >>> on premesis... >>> >>> Would not such an active device be quite appropriate there? >> >>You may consider it appropriate from a financial or moral perspective, >>but it is absolutely wrong under the communications act of 1934 as >>amended. >> >>The following is an oversimplification and IANAL, but generally: >> >>You are _NOT_ allowed to intentionally cause harmful interference with a >>signal for any reason. If you are the primary user on a frequency, you >>are allowed to conduct your normal operations without undue concern for >>other users of the same spectrum, but you are not allowed to >>deliberately interfere with any secondary user just for the sake of >>interfering with them. >> >>The kind of active devices being discussed and the activities of the >>hotel in question appear to have run well afoul of these regulations. >> >>As someone else said, owning the property does not constitute ownership >>of the airwaves within the boundaries of the property, at least in the >>US (and I suspect in most if not all ITU countries). >> >>Owen >> > >Serious question: do the FCC regulations on RF spectrum interference >extend beyond layer 1? I would assume that blasting a bunch of RF noise >would be pretty obviously out of bounds, but my understanding is that >the mechanisms described for rogue AP squashing operate at L2. The >*effect* is to render the wireless medium pretty much useless for its >intended purpose, but that's accomplished by the use (abuse?) of higher >layer control mechanisms. > >I'm not condoning this, but do the FCC regulations RF interference >apply? Do they have authority above L1 in this case? > >-- >Hugo From hugo at slabnet.com Sat Oct 4 02:57:07 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 19:57:07 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: <20141004025707.GD1424@bamboo.slabnet.com> Looks like you cut off, but: >Except that this is the difference between what happens at a Marriott >and what would happen at a business that was running rogue AP >detection. In the business the portable AP would be trying to look like >the network that the company operated so as to siphon off legitimate >users. In a hotel the portable AP would be trying to create a >different, separate network. And so your thesis does not hold. But it's not a completely discrete network. It is a subset of the existing network in the most common example of e.g. a WLAN + NAT device providing access to additional clients, or at least an adjacent network attached to the existing one. Okay: theoretically a guest could spin up a hotspot and not attach it to the hotel network at all, but I'm assuming that's a pretty tiny edge case. As the administration of the hotel/org network, I'm within bounds to say you're not allowed attach unauthorized devices to the network or extend the network and that should be fair in "my network, my rules", no? And so I can take action against a breach of those terms. The hotspot is a separate network, but I don't have to allow it to connect to my network. I guess that points towards killing the wired port as a better method, as doing deauth on the hotspot(s) WLAN(s) would mean that you are participating in the separate network(s) and causing harm there rather than at the attachment point. But what then of the duplicate SSID of the nefarious user at the business? What recourse does the business have while still staying in bounds? -- Hugo On Fri 2014-Oct-03 22:27:06 -0400, Jay Ashworth wrote: >Except that this is the difference between what happens at a Marriott and what would happen at a business that was running rogue AP detection. In the business the portable AP would be trying to look like the network that the company operated so as to siphon off legitimate users. In a hotel the portable AP would be trying to create a different, separate network. And so your thesis does not hold. > >I think this is the distinction we need. Because it's clear that the business thing should be able to happen and the hotel thing should > >On October 3, 2014 10:25:22 PM EDT, Hugo Slabbert wrote: >>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>wrote: >> >>>IANAL, but I believe they are. State laws may also apply (e.g. >>California >>>Code - Section 502). In California, it is illegal to "knowingly and >>>without permission disrupts or causes the disruption of computer >>services >>>or denies or causes the denial of computer services to an authorized >>user >>>of a computer, computer system, or computer network." Blocking access >>to >>>somebody's personal hot spot most likely qualifies. >> >>My guess would be that the hotel or other organizations using the >>blocking tech would probably just say the users/admin of the rogue APs >>are not authorized users as setting up said AP would probably be in >>contravention of the AUP of the hotel/org network. >> >>> >>>/Mike >>> >>> >> >>-- >>Hugo >> >>>On 10/3/14 5:15 PM, "Mike Hale" wrote: >>> >>>>So does that mean the anti-rogue AP technologies by the various >>>>vendors are illegal if used in the US? >>>> >>>>On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >>>>> ----- Original Message ----- >>>>>> From: "Ricky Beam" >>>>> >>>>>> It doesn't. The DEAUTH management frame is not encrypted and >>carries no >>>>>> authentication. The 802.11 spec only requires a reason code be >>>>>> provided. >>>>> >>>>> What's the code for E_GREEDY? >>>>> >>>>> Cheers, >>>>> -- jra >>>>> -- >>>>> Jay R. Ashworth Baylink >>>>>jra at baylink.com >>>>> Designer The Things I Think >>>>>RFC 2100 >>>>> Ashworth & Associates http://www.bcp38.info 2000 >>Land >>>>>Rover DII >>>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 >>727 >>>>>647 1274 >>>> >>>> >>>> >>>>-- >>>>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >>> >>> > >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From hugo at slabnet.com Sat Oct 4 03:04:08 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 20:04:08 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: <20141004030408.GE1424@bamboo.slabnet.com> On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman wrote: >On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: > >>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>wrote: >> >>>IANAL, but I believe they are. State laws may also apply (e.g. >>>California >>>Code - Section 502). In California, it is illegal to "knowingly and >>>without permission disrupts or causes the disruption of computer services >>>or denies or causes the denial of computer services to an authorized user >>>of a computer, computer system, or computer network." Blocking access to >>>somebody's personal hot spot most likely qualifies. >> >>My guess would be that the hotel or other organizations using the >>blocking tech would probably just say the users/admin of the rogue APs >>are not authorized users as setting up said AP would probably be in >>contravention of the AUP of the hotel/org network. > >They can say anything they want, it does not make it legal. > >There's no such thing as a "rogue" AP in this context. I can run an >access point almost anywhere I want (there are limits established by the >FCC in some areas) and it does not matter who owns the land underneath. >They have no authority to decide whether or not my access point is >"authorized." They can certainly refuse to connect me to their wired >network; and they can disconnect me if they decide I am making >inappropriate use of their network -- but they have no legal authority to >interfere with my wireless transmissions on my own network (be it my >personal hotspot, WiFi router, etc.). FWIW, the same is true in almost >all corporate environments as well. Thanks; I think that's the distinction I was looking for here. By spoofing deauth, the org is actively/knowingly participating on *my network* and causing harm to it without necessarily having proof that *my network* is in any way attached to *their network*. The assumption in the hotel case is likely that the WLANs of the "rogue" APs they're targeting are attached to their wired network and are attempts to extend that wireless network without authorization (and that's probably generally a pretty safe assumption), but that doesn't forgive causing harm to that WLAN. There's no reason they can't cut off the wired port of the AP if it is connected to the org's network as that's their attachment point and their call, but spoofed deauth stuff does seem to be out of bounds. I'm not clear on whether it runs afoul of FCC regs as it's not RF interference directly but rather an (ab)use of higher layer control mechanisms operating on that spectrum, but it probably does run afoul of most "thou shalt not harm other networks" legislation like the California example. > >/Mike > > -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From ops.lists at gmail.com Sat Oct 4 03:07:32 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 4 Oct 2014 08:37:32 +0530 Subject: Marriott wifi blocking In-Reply-To: <20141004025707.GD1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: Wifi offered by a carrier citywide, or free wifi signals from a nearby hotel / park / coffee shop.. On 04-Oct-2014 8:29 am, "Hugo Slabbert" wrote: > attached to the existing one. > Okay: theoretically a guest could > spin up a hotspot and not attach > it to the hotel network at all, but > I'm assuming that's a pretty tiny > edge case. > From Valdis.Kletnieks at vt.edu Sat Oct 4 03:09:22 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Oct 2014 23:09:22 -0400 Subject: Marriott wifi blocking In-Reply-To: Your message of "Fri, 03 Oct 2014 20:31:56 -0500." <542F4E0C.4030203@cox.net> References: <542F4E0C.4030203@cox.net> Message-ID: <79204.1412392162@turing-police.cc.vt.edu> On Fri, 03 Oct 2014 20:31:56 -0500, Larry Sheldon said: > What it is about red-colored APs that is offensive? I have never seen one. It's a color code that indicates it's an RFC3514-compliant device. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tagno25 at gmail.com Sat Oct 4 03:11:47 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Fri, 3 Oct 2014 22:11:47 -0500 Subject: Marriott wifi blocking In-Reply-To: <542F2E23.2040404@bogus.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> <542F2E23.2040404@bogus.com> Message-ID: http://www.arrl.org/part-15-radio-frequency-devices#Definitions http://www.ecfr.gov/cgi-bin/text-idx?node=pt47.1.15 (m) Harmful interference. Any emission, radiation or induction that endangers the functioning of a radio navigation service or of other safety services or seriously degrades, obstructs or repeatedly interrupts a radiocommunications service operating in accordance with this chapter. On Oct 3, 2014 6:17 PM, "joel jaeggli" wrote: > On 10/3/14 6:01 PM, John Schiel wrote: > > > > On 10/03/2014 03:23 PM, Keenan Tims wrote: > >>> The question here is what is authorized and what is not. Was this to > >>> protect their network from rogues, or protect revenue from captive > >>> customers. > >> I can't imagine that any 'AP-squashing' packets are ever authorized, > >> outside of a lab. The wireless spectrum is shared by all, regardless of > >> physical locality. Because it's your building doesn't mean you own the > >> spectrum. > > > > +1 > > > >> > >> My reading of this is that these features are illegal, period. Rogue AP > >> detection is one thing, and disabling them via network or > >> "administrative" (ie. eject the guest) means would be fine, but > >> interfering with the wireless is not acceptable per the FCC regulations. > >> > >> Seems like common sense to me. If the FCC considers this 'interference', > >> which it apparently does, then devices MUST NOT intentionally interfere. > > > > I would expect interfering for defensive purposes **only** would be > > acceptable. > > if you have a device licensed under fcc part 15 it may not cause harmful > interference to other users of the spectrum. > > > --John > > > >> > >> K > > > > > From hugo at slabnet.com Sat Oct 4 03:26:39 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 20:26:39 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: <20141004032639.GF1424@bamboo.slabnet.com> On Sat 2014-Oct-04 08:37:32 +0530, Suresh Ramasubramanian wrote: >Wifi offered by a carrier citywide, or free wifi signals from a nearby >hotel / park / coffee shop.. Perfect example (thanks) of why cutting off network attachment points would be fair game while effectively attacking other WLANs has collateral damage. > >On 04-Oct-2014 8:29 am, "Hugo Slabbert" wrote: > >> attached to the existing one. >> Okay: theoretically a guest could >> spin up a hotspot and not attach >> it to the hotel network at all, but >> I'm assuming that's a pretty tiny >> edge case. >> -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jra at baylink.com Sat Oct 4 03:32:39 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 03 Oct 2014 23:32:39 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141004030408.GE1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> Message-ID: Hugo, I still don't think that you have quite made it to the distinction that we are looking for here. In the case of the hotel, we are talking about an access point that connects via 4G to a cellular carrier. An access point that attempts to create its own network for the subscribers devices. A network disjoint from the network provided by the hotel or its contractor. This is a different case from the circumstance in a business office where equipment is deployed to prevent someone from walking in with an access point /which pretends to be part of the network which the office runs./ In the latter case, the security hardware is justified in deassociating people from the rogue access point, /because it is pretending to be part of a network it is not authorized to be part of/. In the Marriott case, that is not the circumstance. The networks which the deauth probes are being aimed at are networks which are advertising themselves as being /separate from the network operated by the hotel/, and this is the distinction that makes Marriott's behavior is unacceptable. (In my opinion; I am NOT a lawyer. If following my advice breaks something, you get to keep both pieces.) On October 3, 2014 11:04:08 PM EDT, Hugo Slabbert wrote: >On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman >wrote: > >>On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: >> >>>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>>wrote: >>> >>>>IANAL, but I believe they are. State laws may also apply (e.g. >>>>California >>>>Code - Section 502). In California, it is illegal to "knowingly and >>>>without permission disrupts or causes the disruption of computer >services >>>>or denies or causes the denial of computer services to an authorized >user >>>>of a computer, computer system, or computer network." Blocking >access to >>>>somebody's personal hot spot most likely qualifies. >>> >>>My guess would be that the hotel or other organizations using the >>>blocking tech would probably just say the users/admin of the rogue >APs >>>are not authorized users as setting up said AP would probably be in >>>contravention of the AUP of the hotel/org network. >> >>They can say anything they want, it does not make it legal. >> >>There's no such thing as a "rogue" AP in this context. I can run an >>access point almost anywhere I want (there are limits established by >the >>FCC in some areas) and it does not matter who owns the land >underneath. >>They have no authority to decide whether or not my access point is >>"authorized." They can certainly refuse to connect me to their wired >>network; and they can disconnect me if they decide I am making >>inappropriate use of their network -- but they have no legal authority >to >>interfere with my wireless transmissions on my own network (be it my >>personal hotspot, WiFi router, etc.). FWIW, the same is true in >almost >>all corporate environments as well. > >Thanks; I think that's the distinction I was looking for here. By >spoofing deauth, the org is actively/knowingly participating on *my >network* and causing harm to it without necessarily having proof that >*my network* is in any way attached to *their network*. The assumption > >in the hotel case is likely that the WLANs of the "rogue" APs they're >targeting are attached to their wired network and are attempts to >extend >that wireless network without authorization (and that's probably >generally a pretty safe assumption), but that doesn't forgive causing >harm to that WLAN. There's no reason they can't cut off the wired port > >of the AP if it is connected to the org's network as that's their >attachment point and their call, but spoofed deauth stuff does seem to >be out of bounds. > >I'm not clear on whether it runs afoul of FCC regs as it's not RF >interference directly but rather an (ab)use of higher layer control >mechanisms operating on that spectrum, but it probably does run afoul >of >most "thou shalt not harm other networks" legislation like the >California example. > >> >>/Mike >> >> > >-- >Hugo -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From hugo at slabnet.com Sat Oct 4 03:45:48 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 Oct 2014 20:45:48 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> Message-ID: <20141004034548.GG1424@bamboo.slabnet.com> Jay, Thanks; I think I was stretching this a bit far beyond just the Marriott example. Killing hotspots of completely discrete networks "because $$$" is heinous. I had extended this to e.g.: 1. Hotel charges for either wired or wireless access per device and has network policies to that effect. 2. Guest pays for a single device and hooks up an AP or AP/NAT combo to the wired port. 3. User piggybacks multiple devices on that device's WLAN. ...to try to flesh out the scenarios. In the attempt I went a bit far off the reservation. Apologies for the noise. -- Hugo On Fri 2014-Oct-03 23:32:39 -0400, Jay Ashworth wrote: >Hugo, I still don't think that you have quite made it to the distinction that we are looking for here. > >In the case of the hotel, we are talking about an access point that connects via 4G to a cellular carrier. An access point that attempts to create its own network for the subscribers devices. A network disjoint from the network provided by the hotel or its contractor. > >This is a different case from the circumstance in a business office where equipment is deployed to prevent someone from walking in with an access point /which pretends to be part of the network which the office runs./ > >In the latter case, the security hardware is justified in deassociating people from the rogue access point, /because it is pretending to be part of a network it is not authorized to be part of/. > >In the Marriott case, that is not the circumstance. The networks which the deauth probes are being aimed at are networks which are advertising themselves as being /separate from the network operated by the hotel/, and this is the distinction that makes Marriott's behavior is unacceptable. > >(In my opinion; I am NOT a lawyer. If following my advice breaks something, you get to keep both pieces.) > >On October 3, 2014 11:04:08 PM EDT, Hugo Slabbert wrote: >>On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman >>wrote: >> >>>On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: >>> >>>>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>>>wrote: >>>> >>>>>IANAL, but I believe they are. State laws may also apply (e.g. >>>>>California >>>>>Code - Section 502). In California, it is illegal to "knowingly and >>>>>without permission disrupts or causes the disruption of computer >>services >>>>>or denies or causes the denial of computer services to an authorized >>user >>>>>of a computer, computer system, or computer network." Blocking >>access to >>>>>somebody's personal hot spot most likely qualifies. >>>> >>>>My guess would be that the hotel or other organizations using the >>>>blocking tech would probably just say the users/admin of the rogue >>APs >>>>are not authorized users as setting up said AP would probably be in >>>>contravention of the AUP of the hotel/org network. >>> >>>They can say anything they want, it does not make it legal. >>> >>>There's no such thing as a "rogue" AP in this context. I can run an >>>access point almost anywhere I want (there are limits established by >>the >>>FCC in some areas) and it does not matter who owns the land >>underneath. >>>They have no authority to decide whether or not my access point is >>>"authorized." They can certainly refuse to connect me to their wired >>>network; and they can disconnect me if they decide I am making >>>inappropriate use of their network -- but they have no legal authority >>to >>>interfere with my wireless transmissions on my own network (be it my >>>personal hotspot, WiFi router, etc.). FWIW, the same is true in >>almost >>>all corporate environments as well. >> >>Thanks; I think that's the distinction I was looking for here. By >>spoofing deauth, the org is actively/knowingly participating on *my >>network* and causing harm to it without necessarily having proof that >>*my network* is in any way attached to *their network*. The assumption >> >>in the hotel case is likely that the WLANs of the "rogue" APs they're >>targeting are attached to their wired network and are attempts to >>extend >>that wireless network without authorization (and that's probably >>generally a pretty safe assumption), but that doesn't forgive causing >>harm to that WLAN. There's no reason they can't cut off the wired port >> >>of the AP if it is connected to the org's network as that's their >>attachment point and their call, but spoofed deauth stuff does seem to >>be out of bounds. >> >>I'm not clear on whether it runs afoul of FCC regs as it's not RF >>interference directly but rather an (ab)use of higher layer control >>mechanisms operating on that spectrum, but it probably does run afoul >>of >>most "thou shalt not harm other networks" legislation like the >>California example. >> >>> >>>/Mike >>> >>> >> >>-- >>Hugo > >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jra at baylink.com Sat Oct 4 03:53:36 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 03 Oct 2014 23:53:36 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141004034548.GG1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> <20141004034548.GG1424@bamboo.slabnet.com> Message-ID: No problem, Hugo. In fact, if you paid for Wired service and plugged your own router in, you would still be creating your own network, and not pretending to be the hotel's network. At the RF layer. So it would not be legal for them to zap that either. Doing so might /violate your agreement for the wired internet/, but that's a problem up in layer 10... (People, money, lawyers) On October 3, 2014 11:45:48 PM EDT, Hugo Slabbert wrote: >Jay, > >Thanks; I think I was stretching this a bit far beyond just the >Marriott >example. Killing hotspots of completely discrete networks "because >$$$" >is heinous. I had extended this to e.g.: > >1. Hotel charges for either wired or wireless access per device and >has >network policies to that effect. >2. Guest pays for a single device and hooks up an AP or AP/NAT combo >to >the wired port. >3. User piggybacks multiple devices on that device's WLAN. > >...to try to flesh out the scenarios. In the attempt I went a bit far >off the reservation. Apologies for the noise. > >-- >Hugo > >On Fri 2014-Oct-03 23:32:39 -0400, Jay Ashworth >wrote: > >>Hugo, I still don't think that you have quite made it to the >distinction that we are looking for here. >> >>In the case of the hotel, we are talking about an access point that >connects via 4G to a cellular carrier. An access point that attempts to >create its own network for the subscribers devices. A network disjoint >from the network provided by the hotel or its contractor. >> >>This is a different case from the circumstance in a business office >where equipment is deployed to prevent someone from walking in with an >access point /which pretends to be part of the network which the office >runs./ >> >>In the latter case, the security hardware is justified in >deassociating people from the rogue access point, /because it is >pretending to be part of a network it is not authorized to be part of/. >> >>In the Marriott case, that is not the circumstance. The networks which >the deauth probes are being aimed at are networks which are advertising >themselves as being /separate from the network operated by the hotel/, >and this is the distinction that makes Marriott's behavior is >unacceptable. >> >>(In my opinion; I am NOT a lawyer. If following my advice breaks >something, you get to keep both pieces.) >> >>On October 3, 2014 11:04:08 PM EDT, Hugo Slabbert >wrote: >>>On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman >>>wrote: >>> >>>>On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: >>>> >>>>>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman > >>>>>wrote: >>>>> >>>>>>IANAL, but I believe they are. State laws may also apply (e.g. >>>>>>California >>>>>>Code - Section 502). In California, it is illegal to "knowingly >and >>>>>>without permission disrupts or causes the disruption of computer >>>services >>>>>>or denies or causes the denial of computer services to an >authorized >>>user >>>>>>of a computer, computer system, or computer network." Blocking >>>access to >>>>>>somebody's personal hot spot most likely qualifies. >>>>> >>>>>My guess would be that the hotel or other organizations using the >>>>>blocking tech would probably just say the users/admin of the rogue >>>APs >>>>>are not authorized users as setting up said AP would probably be in >>>>>contravention of the AUP of the hotel/org network. >>>> >>>>They can say anything they want, it does not make it legal. >>>> >>>>There's no such thing as a "rogue" AP in this context. I can run an >>>>access point almost anywhere I want (there are limits established by >>>the >>>>FCC in some areas) and it does not matter who owns the land >>>underneath. >>>>They have no authority to decide whether or not my access point is >>>>"authorized." They can certainly refuse to connect me to their >wired >>>>network; and they can disconnect me if they decide I am making >>>>inappropriate use of their network -- but they have no legal >authority >>>to >>>>interfere with my wireless transmissions on my own network (be it my >>>>personal hotspot, WiFi router, etc.). FWIW, the same is true in >>>almost >>>>all corporate environments as well. >>> >>>Thanks; I think that's the distinction I was looking for here. By >>>spoofing deauth, the org is actively/knowingly participating on *my >>>network* and causing harm to it without necessarily having proof that >>>*my network* is in any way attached to *their network*. The >assumption >>> >>>in the hotel case is likely that the WLANs of the "rogue" APs they're >>>targeting are attached to their wired network and are attempts to >>>extend >>>that wireless network without authorization (and that's probably >>>generally a pretty safe assumption), but that doesn't forgive causing >>>harm to that WLAN. There's no reason they can't cut off the wired >port >>> >>>of the AP if it is connected to the org's network as that's their >>>attachment point and their call, but spoofed deauth stuff does seem >to >>>be out of bounds. >>> >>>I'm not clear on whether it runs afoul of FCC regs as it's not RF >>>interference directly but rather an (ab)use of higher layer control >>>mechanisms operating on that spectrum, but it probably does run afoul >>>of >>>most "thou shalt not harm other networks" legislation like the >>>California example. >>> >>>> >>>>/Mike >>>> >>>> >>> >>>-- >>>Hugo >> >>-- >>Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >-- >Hugo -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From dseagrav at humancapitaldev.com Sat Oct 4 03:57:29 2014 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Fri, 3 Oct 2014 22:57:29 -0500 Subject: Marriott wifi blocking In-Reply-To: <20141004034548.GG1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> <20141004034548.GG1424@bamboo.slabnet.com> Message-ID: <1AFC77DF-48D8-4AB6-A31D-97072DE2765F@humancapitaldev.com> On Oct 3, 2014, at 10:45 PM, Hugo Slabbert wrote: > Jay, > > Killing hotspots of completely discrete networks "because $$$" is heinous. I had extended this to e.g.: > It’s not just Marriott doing this; A friend of mine went to a convention near DC and found the venue was doing something like this. I don’t know if the method was the same, but he reported that any time he connected to his phone he would be disconnected “nearly immediately". He mentioned this to a con staffer and was told you had to rent internet access from the venue, it cost several hundred dollars per day. Same for electricity, about which he was told “If you have to ask how much it costs, you cannot afford it.” From jay at west.net Sat Oct 4 04:30:12 2014 From: jay at west.net (Jay Hennigan) Date: Fri, 03 Oct 2014 21:30:12 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004025707.GD1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: <542F77D4.7020606@west.net> On 10/3/14, 7:57 PM, Hugo Slabbert wrote: > But it's not a completely discrete network. It is a subset of the > existing network in the most common example of e.g. a WLAN + NAT device > providing access to additional clients, or at least an adjacent network > attached to the existing one. Okay: theoretically a guest could spin up > a hotspot and not attach it to the hotel network at all, but I'm > assuming that's a pretty tiny edge case. The appropriate remedy would be to deny access to the WLAN+NAT device from your host network, not to interfere with its communication to its clients. Or ask the guest operating it to leave the premises. A guest spinning up a hotspot not connected to the hotel network is far from an edge case. Cellular 3G/4G/LTE-to-hotspot devices are quite common and widely deployed. Tethering one's laptop to one's smartphone is also very common. Jamming such communications does nothing to protect one's own wi-fi, only to protect one's profits. > As the administration of the hotel/org network, I'm within bounds to say > you're not allowed attach unauthorized devices to the network or extend > the network and that should be fair in "my network, my rules", no? And > so I can take action against a breach of those terms. As long as it's a legal action, such as denying the MAC of the unauthorized device to your network, absolutely. In this case it's someone else's network, hence not your rules. > The hotspot is a separate network, but I don't have to allow it to > connect to my network. I guess that points towards killing the wired > port as a better method, as doing deauth on the hotspot(s) WLAN(s) would > mean that you are participating in the separate network(s) and causing > harm there rather than at the attachment point. Precisely. > But what then of the duplicate SSID of the nefarious user at the > business? What recourse does the business have while still staying in > bounds? As long as the nefarious user isn't connecting to the business's network, none. There are likely hundreds of thousands if not millions of networks whose SSID is 'Linksys', duplicated willy-nilly worldwide. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From msa at latt.net Sat Oct 4 04:25:40 2014 From: msa at latt.net (Majdi S. Abbas) Date: Sat, 4 Oct 2014 00:25:40 -0400 Subject: Marriott wifi blocking In-Reply-To: <1AFC77DF-48D8-4AB6-A31D-97072DE2765F@humancapitaldev.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> <20141004034548.GG1424@bamboo.slabnet.com> <1AFC77DF-48D8-4AB6-A31D-97072DE2765F@humancapitaldev.com> Message-ID: <20141004042540.GA21720@puck.nether.net> On Fri, Oct 03, 2014 at 10:57:29PM -0500, Daniel Seagraves wrote: > It?s not just Marriott doing this; A friend of mine went to a convention > near DC and found the venue was doing something like this. I don?t know if > the method was the same, but he reported that any time he connected to his > phone he would be disconnected ?nearly immediately". He mentioned this to a > con staffer and was told you had to rent internet access from the venue, it > cost several hundred dollars per day. Same for electricity, about which he I've seen this in a few places, but if anyone encounters similar behavior, I suggest the following: - Document the incident. - Identify the make and model of the access point, or controller, and be sure to pass along this information to the FCC's OET: http://transition.fcc.gov/oet/ Vendors really need to start losing their US device certification for devices that include advertised features that violate US law. It would put a stop to this sort of thing pretty quickly. --msa From jay at west.net Sat Oct 4 04:34:53 2014 From: jay at west.net (Jay Hennigan) Date: Fri, 03 Oct 2014 21:34:53 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004030408.GE1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> Message-ID: <542F78ED.4000508@west.net> On 10/3/14, 8:04 PM, Hugo Slabbert wrote: > I'm not clear on whether it runs afoul of FCC regs as it's not RF > interference directly but rather an (ab)use of higher layer control > mechanisms operating on that spectrum, but it probably does run afoul of > most "thou shalt not harm other networks" legislation like the > California example. You can't get to layer 2 or layer 3 without layer 1. The abuse of higher layer control protocols requires an RF transmitter within the radio spectrum, hence it is interference. It is a much more selectively targeted type of interference than broadband noise, but it's very obviously interference over radio frequencies by any definition. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From owen at delong.com Sat Oct 4 04:31:34 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 21:31:34 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004022522.GB1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: <825BC3BF-FE3C-41A9-A6F1-47C569C59512@delong.com> The hotel is being fined for blocking/jamming users setting up wifi via mobile technologies and such, not using the hotel's network. Hard for me to imagine how the hotel gets to insert itself into any applicable AUP in that scenario. Owen > On Oct 3, 2014, at 19:25, Hugo Slabbert wrote: > >> On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman wrote: >> >> IANAL, but I believe they are. State laws may also apply (e.g. California >> Code - Section 502). In California, it is illegal to "knowingly and >> without permission disrupts or causes the disruption of computer services >> or denies or causes the denial of computer services to an authorized user >> of a computer, computer system, or computer network." Blocking access to >> somebody's personal hot spot most likely qualifies. > > My guess would be that the hotel or other organizations using the blocking tech would probably just say the users/admin of the rogue APs are not authorized users as setting up said AP would probably be in contravention of the AUP of the hotel/org network. > >> >> /Mike >> >> > > -- > Hugo > >>> On 10/3/14 5:15 PM, "Mike Hale" wrote: >>> >>> So does that mean the anti-rogue AP technologies by the various >>> vendors are illegal if used in the US? >>> >>>> On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >>>> ----- Original Message ----- >>>>> From: "Ricky Beam" >>>> >>>>> It doesn't. The DEAUTH management frame is not encrypted and carries no >>>>> authentication. The 802.11 spec only requires a reason code be >>>>> provided. >>>> >>>> What's the code for E_GREEDY? >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink >>>> jra at baylink.com >>>> Designer The Things I Think >>>> RFC 2100 >>>> Ashworth & Associates http://www.bcp38.info 2000 Land >>>> Rover DII >>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >>>> 647 1274 >>> >>> >>> >>> -- >>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> From owen at delong.com Sat Oct 4 04:35:28 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 21:35:28 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004024233.GC1424@bamboo.slabnet.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <20141003231228.GA79197@wakko.typo.org> <20141004024233.GC1424@bamboo.slabnet.com> Message-ID: <180004E4-4F5B-4C05-BFCA-EA4525547078@delong.com> If the signal that is causing the harmful interference is a radio transmission, then the FCC doesn't differentiate between noise and intelligent harmful interference. If you interfere elsewhere on the wire or without transmitting, you might avoid the part 15 rules about causing harmful interference. If you transmit a signal over the air, then the FCC has authority and requires that you not cause harmful interference. Owen > On Oct 3, 2014, at 19:42, Hugo Slabbert wrote: > >> On Fri 2014-Oct-03 16:49:49 -0700, Owen DeLong wrote: >> >> >>> On Oct 3, 2014, at 16:12 , Wayne E Bouchard wrote: >>> >>> On Fri, Oct 03, 2014 at 02:23:46PM -0700, Keenan Tims wrote: >>>>> The question here is what is authorized and what is not. Was this to protect their network from rogues, or protect revenue from captive customers. >>>> >>>> I can't imagine that any 'AP-squashing' packets are ever authorized, >>>> outside of a lab. The wireless spectrum is shared by all, regardless of >>>> physical locality. Because it's your building doesn't mean you own the >>>> spectrum. >>> >>> I think that depends on the terms of your lease agreement. Could not >>> a hotel or conference center operate reserve the right to employ >>> active devices to disable any unauthorized wireless systems? Perhaps >>> because they want to charge to provide that service, because they >>> don't want errant signals leaking from their building, a rogue device >>> could be considered an intruder and represent a risk to the network, >>> or because they don't want someone setting up a system that would >>> interfere with their wireless gear and take down other clients who are >>> on premesis... >>> >>> Would not such an active device be quite appropriate there? >> >> You may consider it appropriate from a financial or moral perspective, but it is absolutely wrong under the communications act of 1934 as amended. >> >> The following is an oversimplification and IANAL, but generally: >> >> You are _NOT_ allowed to intentionally cause harmful interference with a signal for any reason. If you are the primary user on a frequency, you are allowed to conduct your normal operations without undue concern for other users of the same spectrum, but you are not allowed to deliberately interfere with any secondary user just for the sake of interfering with them. >> >> The kind of active devices being discussed and the activities of the hotel in question appear to have run well afoul of these regulations. >> >> As someone else said, owning the property does not constitute ownership of the airwaves within the boundaries of the property, at least in the US (and I suspect in most if not all ITU countries). >> >> Owen > > Serious question: do the FCC regulations on RF spectrum interference extend beyond layer 1? I would assume that blasting a bunch of RF noise would be pretty obviously out of bounds, but my understanding is that the mechanisms described for rogue AP squashing operate at L2. The *effect* is to render the wireless medium pretty much useless for its intended purpose, but that's accomplished by the use (abuse?) of higher layer control mechanisms. > > I'm not condoning this, but do the FCC regulations RF interference apply? Do they have authority above L1 in this case? > > -- > Hugo From owen at delong.com Sat Oct 4 04:39:19 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 21:39:19 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004025707.GD1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: <134749D8-1634-4025-881D-DF8CBB683B3A@delong.com> If there were a duplicate SSID, the. The nefarious user is the one causing illegal harmful interference. However, as I understand the case in question, Marriott was blocking stand-up mobile hotspots not attached to their wired network or bridged/routed through their wifi. As you pointed out, even if this were unauthorized extension of the Marriott network, Marriott's legitimate response would have been disconnecting the extension from their network, not causing harmful interference to the other network. Owen > On Oct 3, 2014, at 19:57, Hugo Slabbert wrote: > > Looks like you cut off, but: > >> Except that this is the difference between what happens at a Marriott and what would happen at a business that was running rogue AP detection. In the business the portable AP would be trying to look like the network that the company operated so as to siphon off legitimate users. In a hotel the portable AP would be trying to create a different, separate network. And so your thesis does not hold. > > But it's not a completely discrete network. It is a subset of the existing network in the most common example of e.g. a WLAN + NAT device providing access to additional clients, or at least an adjacent network attached to the existing one. Okay: theoretically a guest could spin up a hotspot and not attach it to the hotel network at all, but I'm assuming that's a pretty tiny edge case. > > As the administration of the hotel/org network, I'm within bounds to say you're not allowed attach unauthorized devices to the network or extend the network and that should be fair in "my network, my rules", no? And so I can take action against a breach of those terms. > > The hotspot is a separate network, but I don't have to allow it to connect to my network. I guess that points towards killing the wired port as a better method, as doing deauth on the hotspot(s) WLAN(s) would mean that you are participating in the separate network(s) and causing harm there rather than at the attachment point. > > But what then of the duplicate SSID of the nefarious user at the business? What recourse does the business have while still staying in bounds? > > -- > Hugo > >> On Fri 2014-Oct-03 22:27:06 -0400, Jay Ashworth wrote: >> >> Except that this is the difference between what happens at a Marriott and what would happen at a business that was running rogue AP detection. In the business the portable AP would be trying to look like the network that the company operated so as to siphon off legitimate users. In a hotel the portable AP would be trying to create a different, separate network. And so your thesis does not hold. >> >> I think this is the distinction we need. Because it's clear that the business thing should be able to happen and the hotel thing should >> >>> On October 3, 2014 10:25:22 PM EDT, Hugo Slabbert wrote: >>> On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>> wrote: >>> >>>> IANAL, but I believe they are. State laws may also apply (e.g. >>> California >>>> Code - Section 502). In California, it is illegal to "knowingly and >>>> without permission disrupts or causes the disruption of computer >>> services >>>> or denies or causes the denial of computer services to an authorized >>> user >>>> of a computer, computer system, or computer network." Blocking access >>> to >>>> somebody's personal hot spot most likely qualifies. >>> >>> My guess would be that the hotel or other organizations using the >>> blocking tech would probably just say the users/admin of the rogue APs >>> are not authorized users as setting up said AP would probably be in >>> contravention of the AUP of the hotel/org network. >>> >>>> >>>> /Mike >>> >>> -- >>> Hugo >>> >>>>> On 10/3/14 5:15 PM, "Mike Hale" wrote: >>>>> >>>>> So does that mean the anti-rogue AP technologies by the various >>>>> vendors are illegal if used in the US? >>>>> >>>>>> On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >>>>>> ----- Original Message ----- >>>>>>> From: "Ricky Beam" >>>>>> >>>>>>> It doesn't. The DEAUTH management frame is not encrypted and >>> carries no >>>>>>> authentication. The 802.11 spec only requires a reason code be >>>>>>> provided. >>>>>> >>>>>> What's the code for E_GREEDY? >>>>>> >>>>>> Cheers, >>>>>> -- jra >>>>>> -- >>>>>> Jay R. Ashworth Baylink >>>>>> jra at baylink.com >>>>>> Designer The Things I Think >>>>>> RFC 2100 >>>>>> Ashworth & Associates http://www.bcp38.info 2000 >>> Land >>>>>> Rover DII >>>>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 >>> 727 >>>>>> 647 1274 >>>>> >>>>> >>>>> >>>>> -- >>>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > -- > Hugo From jay at west.net Sat Oct 4 04:42:48 2014 From: jay at west.net (Jay Hennigan) Date: Fri, 03 Oct 2014 21:42:48 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141004034548.GG1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> <20141004034548.GG1424@bamboo.slabnet.com> Message-ID: <542F7AC8.9060707@west.net> On 10/3/14, 8:45 PM, Hugo Slabbert wrote: > Jay, > > Thanks; I think I was stretching this a bit far beyond just the Marriott > example. Killing hotspots of completely discrete networks "because $$$" > is heinous. I had extended this to e.g.: > > 1. Hotel charges for either wired or wireless access per device and has > network policies to that effect. OK. > 2. Guest pays for a single device and hooks up an AP or AP/NAT combo to > the wired port. Guest has only a single device connected to hotel's network, which he is paying for. OK. > 3. User piggybacks multiple devices on that device's WLAN. His network, his rules. Hotel has no right to interfere. He only has one device connected to them. Same scenario as that of a residential ISP where a user pays for one dynamic IP address, installs a NAT box and connects several devices to it. If hotel has an AUP that specifically prohibits this, then they are within their rights to disconnect the user from their network, but not to interfere with his network. If they do so he now has his own little private WLAN going nowhere but it works just fine. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From larrysheldon at cox.net Sat Oct 4 04:50:55 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 03 Oct 2014 23:50:55 -0500 Subject: Marriott wifi blocking In-Reply-To: References: <542F4E0C.4030203@cox.net> Message-ID: <542F7CAF.6040200@cox.net> On 10/3/2014 22:09, Valdis.Kletnieks at vt.edu wrote: > On Fri, 03 Oct 2014 20:31:56 -0500, Larry Sheldon said: > >> What it is about red-colored APs that is offensive? I have never seen one. > > It's a color code that indicates it's an RFC3514-compliant device. %^) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Sat Oct 4 05:03:47 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 04 Oct 2014 00:03:47 -0500 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: <542F7FB3.3000005@cox.net> On 10/3/2014 22:26, Hugo Slabbert wrote: > On Sat 2014-Oct-04 08:37:32 +0530, Suresh Ramasubramanian > wrote: > >> Wifi offered by a carrier citywide, or free wifi signals from a nearby >> hotel / park / coffee shop.. > > Perfect example (thanks) of why cutting off network attachment points > would be fair game while effectively attacking other WLANs has > collateral damage. Most crimes not committed by government entities have to go through an indictment-trial-conviction sequence before punisihment is administered. Except in Chicago. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Sat Oct 4 05:08:05 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 04 Oct 2014 00:08:05 -0500 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> Message-ID: <542F80B5.2010502@cox.net> On 10/3/2014 23:31, Owen DeLong wrote: > The hotel is being fined for blocking/jamming users setting up wifi > via mobile technologies and such, not using the hotel's network. Hard > for me to imagine how the hotel gets to insert itself into any > applicable AUP in that scenario. +1 What happens if the AP happens to be stopped at a traffic light outside? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From owen at delong.com Sat Oct 4 06:37:52 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Oct 2014 23:37:52 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F7FB3.3000005@cox.net> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> <542F7FB3.3000005@cox.net> Message-ID: <8A0915B6-575C-4644-9958-A96E7E9C82FC@delong.com> > Most crimes not committed by government entities have to go through an indictment-trial-conviction sequence before punisihment is administered. > > Except in Chicago. Whereas most crimes committed by government entities go through the same process and are then not punished. Owen From larrysheldon at cox.net Sat Oct 4 06:56:15 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 04 Oct 2014 01:56:15 -0500 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> <542F7FB3.3000005@cox.net> Message-ID: <542F9A0F.2070301@cox.net> On 10/4/2014 01:37, Owen DeLong wrote: >> Most crimes not committed by government entities have to go through >> an indictment-trial-conviction sequence before punisihment is >> administered. >> >> Except in Chicago. > > Whereas most crimes committed by government entities go through the > same process and are then not punished. I wasn't going to go there--that gets me banned a lot. But I do think that an related AP at the curb outside is entitled to a trial before the death ray is unleashed against it. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From jay at west.net Sat Oct 4 07:55:05 2014 From: jay at west.net (Jay Hennigan) Date: Sat, 04 Oct 2014 00:55:05 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F7FB3.3000005@cox.net> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> <542F7FB3.3000005@cox.net> Message-ID: <542FA7D9.6000106@west.net> On 10/3/14, 10:03 PM, Larry Sheldon wrote: > On 10/3/2014 22:26, Hugo Slabbert wrote: >> On Sat 2014-Oct-04 08:37:32 +0530, Suresh Ramasubramanian >> wrote: >> >>> Wifi offered by a carrier citywide, or free wifi signals from a nearby >>> hotel / park / coffee shop.. >> >> Perfect example (thanks) of why cutting off network attachment points >> would be fair game while effectively attacking other WLANs has >> collateral damage. > > Most crimes not committed by government entities have to go through an > indictment-trial-conviction sequence before punisihment is administered. > > Except in Chicago. And Ferguson. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From bob at FiberInternetCenter.com Sat Oct 4 13:56:31 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 4 Oct 2014 06:56:31 -0700 Subject: Marriott wifi blocking In-Reply-To: <542F9A0F.2070301@cox.net> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> <542F7FB3.3000005@cox.net> <542F9A0F.2070301@cox.net> Message-ID: <32b17a96303c129f273a706ad88db11f.squirrel@66.201.44.180> > On 10/4/2014 01:37, Owen DeLong wrote: >>> Most crimes not committed by government entities have to go through >>> an indictment-trial-conviction sequence before punisihment is >>> administered. >>> >>> Except in Chicago. >> >> Whereas most crimes committed by government entities go through the >> same process and are then not punished. > > I wasn't going to go there--that gets me banned a lot. > > > But I do think that an related AP at the curb outside is entitled to a > trial before the death ray is unleashed against it. Some laws that are broken require one to remain in jail until trial completion, whenever one is found to be a threat to other members of society. So in a virtual society perhaps virtual cell walls would be appropriate ? Bob Evans CTO From jra at baylink.com Sat Oct 4 17:23:02 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 4 Oct 2014 13:23:02 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: <20141004042540.GA21720@puck.nether.net> Message-ID: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Majdi S. Abbas" > I've seen this in a few places, but if anyone encounters similar > behavior, I suggest the following: > > - Document the incident. > - Identify the make and model of the access point, or > controller, and be sure to pass along this information to > the FCC's OET: http://transition.fcc.gov/oet/ > > Vendors really need to start losing their US device certification > for devices that include advertised features that violate US law. It > would put a stop to this sort of thing pretty quickly. Majdi makes an excellent point, but I want to clarify it, so no one misses the important subtext: It is OK for an enterprise wifi system to make this sort of attack *on rogue APs which are trying to pretend to be part of it (same ESSID). It is NOT OK for an enterprise wifi system to make this sort of attack on APs which *are not trying to pretend to be part of it* (we'll call this The Marriott Attack from now on, right?) Rogue AP prevention is a *useful* feature in enterprise wifi systems... but *that isn't what Marriott was doing*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mike at mtcc.com Sat Oct 4 17:35:54 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 04 Oct 2014 10:35:54 -0700 Subject: Marriott wifi blocking In-Reply-To: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> Message-ID: <54302FFA.30208@mtcc.com> On 10/04/2014 10:23 AM, Jay Ashworth wrote: > > Majdi makes an excellent point, but I want to clarify it, so no one misses > the important subtext: > > It is OK for an enterprise wifi system to make this sort of attack *on rogue > APs which are trying to pretend to be part of it (same ESSID). > > It is NOT OK for an enterprise wifi system to make this sort of attack > on APs which *are not trying to pretend to be part of it* (we'll call this > The Marriott Attack from now on, right?) > > Rogue AP prevention is a *useful* feature in enterprise wifi systems... > but *that isn't what Marriott was doing*. > So I work in a small office in a building that has many "enterprise" wifi's I can see whether I like it or not. What if one of them decided that our wifi was "rogue" and started trying to stamp it out? Mike, this seems like it might be a universally bad idea... From sml at lordsargon.com Sat Oct 4 17:48:11 2014 From: sml at lordsargon.com (SML) Date: Sat, 04 Oct 2014 12:48:11 -0500 Subject: Marriott wifi blocking In-Reply-To: <54302FFA.30208@mtcc.com> References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> <54302FFA.30208@mtcc.com> Message-ID: <8A871F47-475E-44E5-BB2C-B9E95E97A597@lordsargon.com> On 4 Oct 2014, at 12:35, Michael Thomas wrote: > On 10/04/2014 10:23 AM, Jay Ashworth wrote: > So I work in a small office in a building that has many "enterprise" > wifi's I can see > whether I like it or not. What if one of them decided that our wifi > was "rogue" and > started trying to stamp it out? It happens daily. We have 22 offices around the world, each in downtown towers. We use Cisco WLCs, and those controllers see constant deauth frames coming from people above us, below us, and from the four sides around us. It is a real battle. The only thing to do is use lots of APs in the office so as to keep the power levels down. In a couple of cases our office managers personally visited the offices of people above, below, and across from us and discussed the problem. It helped. > Mike, this seems like it might be a universally bad idea... It isn't a bad idea, as we need to protect our corporate networks. But there are unintended consequences, to be sure. From owen at delong.com Sat Oct 4 18:38:11 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Oct 2014 11:38:11 -0700 Subject: Marriott wifi blocking In-Reply-To: <32b17a96303c129f273a706ad88db11f.squirrel@66.201.44.180> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> <542F7FB3.3000005@cox.net> <542F9A0F.2070301@cox.net> <32b17a96303c129f273a706ad88db11f.squirrel@66.201.44.180> Message-ID: <0636EB6F-C8C4-40F8-88E8-F78C91581D9C@delong.com> On Oct 4, 2014, at 06:56 , Bob Evans wrote: >> On 10/4/2014 01:37, Owen DeLong wrote: >>>> Most crimes not committed by government entities have to go through >>>> an indictment-trial-conviction sequence before punisihment is >>>> administered. >>>> >>>> Except in Chicago. >>> >>> Whereas most crimes committed by government entities go through the >>> same process and are then not punished. >> >> I wasn't going to go there--that gets me banned a lot. >> >> >> But I do think that an related AP at the curb outside is entitled to a >> trial before the death ray is unleashed against it. > > Some laws that are broken require one to remain in jail until trial > completion, whenever one is found to be a threat to other members of > society. So in a virtual society perhaps virtual cell walls would be > appropriate ? In a virtual society, nobody's life is endangered. I don't know of any cases (under US law) where someone has been held without bail for economic crimes. Obviously, some societies allow one to be held without bail for almost anything, but I don't think that fits the original premise. Owen From jra at baylink.com Sat Oct 4 18:47:42 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 4 Oct 2014 14:47:42 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: Message-ID: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Marget" > You [I] said: > > > It is OK for an enterprise wifi system to make this sort of attack > > *on rogue APs which are trying to pretend to be part of it (same ESSID). > > I'm curious to hear how you'd rationalize containing a copycat AP > under the current rules. > > In fact, I remain fuzzy on when spoofed de-auth frames would *ever* be okay > when used against unwilling clients within the FCC's jurisdiction given > their position that spoofed control frames constitute interference under > part 15 rules. > > This thread and similar discussions elsewhere contain assertions that > enterprise networks "need to defend themselves" in some circumstances, > or that "containing" an AP with a copycat SSID would certainly be okay. > > I'm not so sure. > > The "need to manage our RF space" arguments ring hollow to me. I certainly > understand why someone would *want* to manage the spectrum, but that's > just not anyone's privilege when using ISM bands. If the need is great > enough, get some licensed spectrum and manage that. I wasn't making that argument. I was making the "if someone tries to pretend to be part of my network, so that my users will inadvertantly attach to them and possibly leak 'classified' data, *then that rogue user is making a 1030 attack on my network*. > A copycat AP is unquestionably hostile, and likely interfering with users, > but I'm unconvinced that the hostility triggers a privilege to attack it > under part 15 rules. In addition to not being allowed to interfere, we also > have: You're not attacking it, per se; you are defensively disconnecting from it *users who are part of your own network*; these are endpoints *you are administratively allowed to exert control over*, from my viewpoint. > 2. This device must accept any interference received, including > interference that may cause undesired operation. > > Certificate-based authentication would solve that problem anyway, > wouldn't it? Probably. And yes, any system big enough to do this stuff is likely big enough to run 1x as well. > A "rogue" AP plugged into a wired port is best solved at the wired port, I'm not sure anyone was actually mooting this. > Even large private campuses like oil refineries probably wouldn't be in the > clear doing this sort of thing unless they're able to stop law enforcement, > delivery drivers, paramedics and firefighters at the gate in order to get > them to agree to receive spoofed de-auth frames. Again: you've shifted topics here from "enterprise rogue protection" (stay off *my* ESSID) to "Marriott Attack" (stay off all ESSIDs that *aren't* mine); different thing entirely. I make a clear distinction (now that it's not 3am :-) between what Marriott is doing, and what enterprises doing rogue protection are doing, as noted above. Still not a lawyer. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From chris at marget.com Sat Oct 4 19:06:01 2014 From: chris at marget.com (Chris Marget) Date: Sat, 4 Oct 2014 15:06:01 -0400 Subject: Marriott wifi blocking In-Reply-To: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Oct 4, 2014 at 2:47 PM, Jay Ashworth wrote: > > ----- Original Message ----- > > From: "Chris Marget" > > > You [I] said: > > > > > It is OK for an enterprise wifi system to make this sort of attack > > > *on rogue APs which are trying to pretend to be part of it (same ESSID). > > > > I'm curious to hear how you'd rationalize containing a copycat AP > > under the current rules. > > > > > > The "need to manage our RF space" arguments ring hollow to me. I certainly > > understand why someone would *want* to manage the spectrum, but that's > > just not anyone's privilege when using ISM bands. If the need is great > > enough, get some licensed spectrum and manage that. > > I wasn't making that argument. Yes, sorry. I presented two arguments. Only the one about copycat SSIDs is yours. > I was making the "if someone tries to pretend to be part of my network, > so that my users will inadvertantly attach to them and possibly leak > 'classified' data, *then that rogue user is making a 1030 attack on my > network*. > > > A copycat AP is unquestionably hostile, and likely interfering with users, > > but I'm unconvinced that the hostility triggers a privilege to attack it > > under part 15 rules. In addition to not being allowed to interfere, we also > > have: > > You're not attacking it, per se; you are defensively disconnecting from > it *users who are part of your own network*; these are endpoints *you are > administratively allowed to exert control over*, from my viewpoint. Okay, so we're not talking about wholesale containment of the copycat AP, but rather management of our own client devices which, by definition, we can't interfere with. Because they're ours. That approach sounds perfectly reasonable. I wonder, absent certificates, how one can be certain about the identity of the client, and if such a narrowly scoped containment mechanism is actually implemented by the various checkboxes available to enterprise wifi administrators. > I make a clear distinction (now that it's not 3am :-) between what Marriott > is doing, and what enterprises doing rogue protection are doing, as noted > above. Is it clear exactly what "enterprises going rogue protection" are up to? I've asked several, gotten wildly different answers. Keeping "my clients" off "copycat APs" sounds reasonable. More aggressive action might not be. Thanks. From mike at mtcc.com Sat Oct 4 19:15:36 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 04 Oct 2014 12:15:36 -0700 Subject: Marriott wifi blocking In-Reply-To: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> Message-ID: <54304758.7070509@mtcc.com> On 10/04/2014 11:47 AM, Jay Ashworth wrote: > > A copycat AP is unquestionably hostile, and likely interfering with users, > but I'm unconvinced that the hostility triggers a privilege to attack it > under part 15 rules. In addition to not being allowed to interfere, we also > have: > You're not attacking it, per se; you are defensively disconnecting from > it *users who are part of your own network*; these are endpoints *you are > administratively allowed to exert control over*, from my viewpoint. > The problem is that there's really no such thing as a "copycat" if the client doesn't have the means of authenticating the destination. If that's really the requirement, people should start bitching to ieee to get destination auth on ap's instead of blatantly asserting that somebody owns a particular ssid because, well, because. Mike From jared at puck.nether.net Sat Oct 4 19:20:22 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 4 Oct 2014 15:20:22 -0400 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> Message-ID: <1243E78C-A885-4A36-B5AB-289186089246@puck.nether.net> Sounds likely at least in unlicensed bands Jared Mauch > On Oct 3, 2014, at 8:15 PM, Mike Hale wrote: > > So does that mean the anti-rogue AP technologies by the various > vendors are illegal if used in the US? > >> On Fri, Oct 3, 2014 at 4:54 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Ricky Beam" >> >>> It doesn't. The DEAUTH management frame is not encrypted and carries no >>> authentication. The 802.11 spec only requires a reason code be >>> provided. >> >> What's the code for E_GREEDY? >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From bross at pobox.com Sat Oct 4 19:39:37 2014 From: bross at pobox.com (Brandon Ross) Date: Sat, 4 Oct 2014 15:39:37 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: <54304758.7070509@mtcc.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> Message-ID: On Sat, 4 Oct 2014, Michael Thomas wrote: > The problem is that there's really no such thing as a "copycat" if the > client doesn't have the means of authenticating the destination. If > that's really the requirement, people should start bitching to ieee to > get destination auth on ap's instead of blatantly asserting that > somebody owns a particular ssid because, well, because. In the enterprise environment that there's been some insistence from folks on this list is a legitimate place to block "rogue" APs, what makes those SSIDs, "yours"? Just because they were used first by the enterprise? That doesn't seem to hold water in an unlicensed environment to me at all. If the Marriott can't do this, I don't think anyone can, legally. Now, granted, if I'm doing it with the intent to disrupt the corporate network or steal data, there's certainly other laws to deal with that, but I don't think even that is justification for spoofed deauth. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From owen at delong.com Sat Oct 4 20:33:13 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Oct 2014 13:33:13 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> Message-ID: <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> On Oct 4, 2014, at 12:39 , Brandon Ross wrote: > On Sat, 4 Oct 2014, Michael Thomas wrote: > >> The problem is that there's really no such thing as a "copycat" if the client doesn't have the means of authenticating the destination. If that's really the requirement, people should start bitching to ieee to get destination auth on ap's instead of blatantly asserting that somebody owns a particular ssid because, well, because. > > In the enterprise environment that there's been some insistence from folks on this list is a legitimate place to block "rogue" APs, what makes those SSIDs, "yours"? Just because they were used first by the enterprise? That doesn't seem to hold water in an unlicensed environment to me at all. Pretty much... Here's why... If you are using an SSID in an area, anyone else using the same SSID later is causing harmful interference to your network. It's a first-come-first-serve situation. Just like amateur radio spectrum... If you're using a frequency to carry on a conversation with someone, other hams have an obligation not to interfere with your conversation (except in an emergency). It's a bit more complicated there, because you're obliged to reasonably accommodate others wishing to use the frequency, but in the case of SSIDs, there's no such requirement. Now, if I start using SSID XYZ in building 1 and someone else is using it in building 3 and the two coverage zones don't overlap, I'm not entitled to extend my XYZ SSID into building 3 when I rent space there, because someone else is using it in that location first. I can only extend my XYZ coverage zone so far as there are no competing XYZ SSIDs in the locations I'm expanding in to. > If the Marriott can't do this, I don't think anyone can, legally. If I set up something on an SSID Marriott is already using, then my bad and they have the right to take appropriate defensive action to protect their network. If I stand up a new network using an SSID Marriott isn't already using, then they have no right to cause harmful interference to that network. Sharing the same channels using different SSIDs, while it may degrade performance (of both networks) isn't technically what I would call "harmful interference", nor is it considered such by the FCC. That's just a matter of sharing the spectrum as intended in the products certified for that service. > Now, granted, if I'm doing it with the intent to disrupt the corporate network or steal data, there's certainly other laws to deal with that, but I don't think even that is justification for spoofed deauth. Depends on whether you were the first one using the SSID in a particular location or not. Sure, this can get ambiguous and difficult to prove, but the reality is that most cases are pretty clear cut and it's usually not hard to tell who is the interloper on a given SSID. Owen From mike at mtcc.com Sat Oct 4 20:44:04 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 04 Oct 2014 13:44:04 -0700 Subject: Marriott wifi blocking In-Reply-To: <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> Message-ID: <54305C14.1000907@mtcc.com> On 10/04/2014 01:33 PM, Owen DeLong wrote: > On Oct 4, 2014, at 12:39 , Brandon Ross wrote: > >> On Sat, 4 Oct 2014, Michael Thomas wrote: >> >>> The problem is that there's really no such thing as a "copycat" if the client doesn't have the means of authenticating the destination. If that's really the requirement, people should start bitching to ieee to get destination auth on ap's instead of blatantly asserting that somebody owns a particular ssid because, well, because. >> In the enterprise environment that there's been some insistence from folks on this list is a legitimate place to block "rogue" APs, what makes those SSIDs, "yours"? Just because they were used first by the enterprise? That doesn't seem to hold water in an unlicensed environment to me at all. > Pretty much... Here's why... > > If you are using an SSID in an area, anyone else using the same SSID later is causing harmful interference to your network. It's a first-come-first-serve situation. Just like amateur radio spectrum... If you're using a frequency to carry on a conversation with someone, other hams have an obligation not to interfere with your conversation (except in an emergency). It's a bit more complicated there, because you're obliged to reasonably accommodate others wishing to use the frequency, but in the case of SSIDs, there's no such requirement. > > Now, if I start using SSID XYZ in building 1 and someone else is using it in building 3 and the two coverage zones don't overlap, I'm not entitled to extend my XYZ SSID into building 3 when I rent space there, because someone else is using it in that location first. > > I can only extend my XYZ coverage zone so far as there are no competing XYZ SSIDs in the locations I'm expanding in to. > >> If the Marriott can't do this, I don't think anyone can, legally. > If I set up something on an SSID Marriott is already using, then my bad and they have the right to take appropriate defensive action to protect their network. > No. Seriously, no. Biggest come, biggest serve doesn't do a damn bit of good dealing with the actual problem which is one of authentication. Think of this with the big I internet without TLS. What you're asking for is complete chaos. Stomping on other AP is an arms race in which nobody wins. If I want to guarantee that I only connect to $MEGACORP AP's, I should be using strong authentication, not AP neutron bombs to clear the battlefield. Mike From brandon at rd.bbc.co.uk Sat Oct 4 20:57:42 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 4 Oct 2014 21:57:42 +0100 (BST) Subject: Marriott wifi blocking Message-ID: <201410042057.VAA25872@sunf10.rd.bbc.co.uk> > From: Jay Ashworth > Again: you've shifted topics here from "enterprise rogue protection" > (stay off *my* ESSID) to "Marriott Attack" (stay off all ESSIDs that > *aren't* mine); different thing entirely. Don't forget the 3rd "stay off this channel go use another" used at large scale events where for the masses to get a workable service a few have to give up the right to spray their wifi on whichever channel they wish. The Marriott may have not been fined had they been doing this rather than "stay off all channels because we wish to charge for them". I've not seen if they were stopping other SSID on all channels or just the ones they were using. brandon From magicsata at gmail.com Fri Oct 3 20:15:28 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 3 Oct 2014 21:15:28 +0100 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: You could monitor it with something like airodump-ng and send deauth packets if its not associated with your own BSSID(s) On 3 October 2014 21:06, David Hubbard wrote: > Saw this article: > > http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ > > The interesting part: > > 'A federal investigation of the Gaylord Opryland Resort and > Convention Center in Nashville found that Marriott employees > had used "containment features of a Wi-Fi monitoring system" > at the hotel to prevent people from accessing their own > personal Wi-Fi networks.' > > I'm aware of how the illegal wifi blocking devices work, but > any idea what legal hardware they were using to effectively > keep their own wifi available but render everyone else's > inaccessible? > > David > From gmoberg at logmatrix.com Fri Oct 3 20:28:14 2014 From: gmoberg at logmatrix.com (Gregory Moberg) Date: Fri, 3 Oct 2014 16:28:14 -0400 Subject: Marriott wifi blocking In-Reply-To: <1412367368703.67558@csuohio.edu> References: <1412367368703.67558@csuohio.edu> Message-ID: I would think this would not sit very well with the providers. They've likely installed equip nearby to the hotel & conv.ctr in order to adequately handle the concentration of devices at that location. True? On Fri, Oct 3, 2014 at 4:16 PM, Michael O Holstein < michael.holstein at csuohio.edu> wrote: > legality is questionable insofar as "this device must not cause harmful > interference" of PartB > but how it works is by sending DEAUTH packets with spoofed MAC addresses > "rouge AP" response on Cisco/Aruba works like this. > > Regards, > > Michael Holstein > Cleveland State University > ________________________________________ > From: NANOG on behalf of David Hubbard < > dhubbard at dino.hostasaurus.com> > Sent: Friday, October 03, 2014 4:06 PM > To: NANOG > Subject: Marriott wifi blocking > > Saw this article: > > http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ > > The interesting part: > > 'A federal investigation of the Gaylord Opryland Resort and > Convention Center in Nashville found that Marriott employees > had used "containment features of a Wi-Fi monitoring system" > at the hotel to prevent people from accessing their own > personal Wi-Fi networks.' > > I'm aware of how the illegal wifi blocking devices work, but > any idea what legal hardware they were using to effectively > keep their own wifi available but render everyone else's > inaccessible? > > David > -- Greg Moberg, Director, NerveCenter Engineering LogMatrix, Inc | http://www.logmatrix.com/ | CommunityForum | Blog Telephone: +1 (800)892-3646 From mysidia at gmail.com Sat Oct 4 22:59:10 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 4 Oct 2014 17:59:10 -0500 Subject: Marriott wifi blocking In-Reply-To: <8A871F47-475E-44E5-BB2C-B9E95E97A597@lordsargon.com> References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> <54302FFA.30208@mtcc.com> <8A871F47-475E-44E5-BB2C-B9E95E97A597@lordsargon.com> Message-ID: On Sat, Oct 4, 2014 at 12:48 PM, SML wrote: > On 4 Oct 2014, at 12:35, Michael Thomas wrote: >> On 10/04/2014 10:23 AM, Jay Ashworth wrote: >> So I work in a small office in a building that has many "enterprise" >> whether I like it or not. What if one of them decided that our wifi was >> "rogue" and>> started trying to stamp it out? > It happens daily. We have 22 offices around the world, each in downtown > towers. We use Cisco WLCs, and those controllers see constant deauth frames > coming from people above us, below us, and from the four sides around us. It > is a real battle. The only thing to do is use lots of APs in the office so > as to keep the power levels down. Well, based on the Marriott incident, it seems that what you need to do is figure out where the Deauths are coming from via direction finding and start sending written notices to your neighbors, and if the behavior persists --- follow them up with some FCC interference complaints. https://esupport.fcc.gov/ccmsforms/form2000.action -- -JH From rbf+nanog at panix.com Sun Oct 5 00:58:07 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 4 Oct 2014 19:58:07 -0500 Subject: Marriott wifi blocking In-Reply-To: <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> Message-ID: <20141005005807.GA24831@panix.com> On Sat, Oct 04, 2014 at 01:33:13PM -0700, Owen DeLong wrote: > > On Oct 4, 2014, at 12:39 , Brandon Ross wrote: > > > On Sat, 4 Oct 2014, Michael Thomas wrote: > > > >> The problem is that there's really no such thing as a "copycat" if > >> the client doesn't have the means of authenticating the > >> destination. If that's really the requirement, people should start > >> bitching to ieee to get destination auth on ap's instead of > >> blatantly asserting that somebody owns a particular ssid because, > >> well, because. > > > > In the enterprise environment that there's been some insistence > > from folks on this list is a legitimate place to block "rogue" APs, > > what makes those SSIDs, "yours"? Just because they were used first > > by the enterprise? That doesn't seem to hold water in an unlicensed > > environment to me at all. > > Pretty much... Here's why... > > If you are using an SSID in an area, anyone else using the same SSID > later is causing harmful interference to your network. It's a > first-come-first-serve situation. Just like amateur radio spectrum... > If you're using a frequency to carry on a conversation with someone, > other hams have an obligation not to interfere with your conversation > (except in an emergency). It's a bit more complicated there, because > you're obliged to reasonably accommodate others wishing to use the > frequency, but in the case of SSIDs, there's no such requirement. > > Now, if I start using SSID XYZ in building 1 and someone else is > using it in building 3 and the two coverage zones don't overlap, I'm > not entitled to extend my XYZ SSID into building 3 when I rent space > there, because someone else is using it in that location first. So your position is that if I start using Starbuck's SSID in a location where there is no Starbuck, and they layer move in to that building, I'm entitled to compel them to not use their SSID? > I can only extend my XYZ coverage zone so far as there are no > competing XYZ SSIDs in the locations I'm expanding in to. Is ther FCC guidance on this, or is this "Regulations As Interpreted By Owen"? > Depends on whether you were the first one using the SSID in a > particular location or not. > > Sure, this can get ambiguous and difficult to prove, but the reality > is that most cases are pretty clear cut and it's usually not hard to > tell who is the interloper on a given SSID. It's usually easy to tell, but I doubt the FCC would find it relevant. There's a lot of amateur lawyering ogain on in this thread, in an area where there's a lot of ambiguity. We don't even know for sure that what Marriott did is illegal -- all we know is that the FCC asserted it was and Mariott decided to settle rather than litigate the matter. And that was an extreme case -- Marriott was making transmissions for the *sole purpose of preventing others from using the spectrum*. -- Brett From lists at mtin.net Sun Oct 5 01:28:20 2014 From: lists at mtin.net (Justin Wilson) Date: Sat, 04 Oct 2014 21:28:20 -0400 Subject: Equinix Sales In-Reply-To: References: Message-ID: I have a contact. I ill dig it up. On 10/3/14, 10:33 AM, "Daniel Corbe" wrote: > >Equinix Sales seem impossible to reach. Should I just give up and go >through a sales agent or can someone from Equinix sales contact me >off-list? > From mpetach at netflight.com Sun Oct 5 02:04:00 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 4 Oct 2014 19:04:00 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141005005807.GA24831@panix.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> Message-ID: On Sat, Oct 4, 2014 at 5:58 PM, Brett Frankenberger wrote: > ... > > So your position is that if I start using Starbuck's SSID in a location > where there is no Starbuck, and they layer move in to that building, > I'm entitled to compel them to not use their SSID? > This would be why commercial entities often use their trademark identifiers as part of the SSID. You can compel them (briefly) not to use the SSID, until they sue you for trademark infringement and serve cease-and-desist orders against you for unlicensed and unauthorized use of the Starbucks name. Totally separate realm of enforcement, and in many ways far more effective. Matt From owen at delong.com Sun Oct 5 06:13:40 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Oct 2014 23:13:40 -0700 Subject: Marriott wifi blocking In-Reply-To: <54305C14.1000907@mtcc.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> Message-ID: <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. Further, you seem to assume a level of control over client behavior that is rare in my experience. Owen > On Oct 4, 2014, at 13:44, Michael Thomas wrote: > >> On 10/04/2014 01:33 PM, Owen DeLong wrote: >>> On Oct 4, 2014, at 12:39 , Brandon Ross wrote: >>> >>>> On Sat, 4 Oct 2014, Michael Thomas wrote: >>>> >>>> The problem is that there's really no such thing as a "copycat" if the client doesn't have the means of authenticating the destination. If that's really the requirement, people should start bitching to ieee to get destination auth on ap's instead of blatantly asserting that somebody owns a particular ssid because, well, because. >>> In the enterprise environment that there's been some insistence from folks on this list is a legitimate place to block "rogue" APs, what makes those SSIDs, "yours"? Just because they were used first by the enterprise? That doesn't seem to hold water in an unlicensed environment to me at all. >> Pretty much... Here's why... >> >> If you are using an SSID in an area, anyone else using the same SSID later is causing harmful interference to your network. It's a first-come-first-serve situation. Just like amateur radio spectrum... If you're using a frequency to carry on a conversation with someone, other hams have an obligation not to interfere with your conversation (except in an emergency). It's a bit more complicated there, because you're obliged to reasonably accommodate others wishing to use the frequency, but in the case of SSIDs, there's no such requirement. >> >> Now, if I start using SSID XYZ in building 1 and someone else is using it in building 3 and the two coverage zones don't overlap, I'm not entitled to extend my XYZ SSID into building 3 when I rent space there, because someone else is using it in that location first. >> >> I can only extend my XYZ coverage zone so far as there are no competing XYZ SSIDs in the locations I'm expanding in to. >> >>> If the Marriott can't do this, I don't think anyone can, legally. >> If I set up something on an SSID Marriott is already using, then my bad and they have the right to take appropriate defensive action to protect their network. > > No. Seriously, no. Biggest come, biggest serve doesn't do a damn bit of good dealing with the actual problem which is > one of authentication. Think of this with the big I internet without TLS. What you're asking for is complete chaos. > > Stomping on other AP is an arms race in which nobody wins. If I want to guarantee that I only connect to $MEGACORP > AP's, I should be using strong authentication, not AP neutron bombs to clear the battlefield. > > Mike From owen at delong.com Sun Oct 5 06:19:57 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Oct 2014 23:19:57 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141005005807.GA24831@panix.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> Message-ID: <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> > On Oct 4, 2014, at 17:58, Brett Frankenberger wrote: > >> On Sat, Oct 04, 2014 at 01:33:13PM -0700, Owen DeLong wrote: >> >>> On Oct 4, 2014, at 12:39 , Brandon Ross wrote: >>> >>>> On Sat, 4 Oct 2014, Michael Thomas wrote: >>>> >>>> The problem is that there's really no such thing as a "copycat" if >>>> the client doesn't have the means of authenticating the >>>> destination. If that's really the requirement, people should start >>>> bitching to ieee to get destination auth on ap's instead of >>>> blatantly asserting that somebody owns a particular ssid because, >>>> well, because. >>> >>> In the enterprise environment that there's been some insistence >>> from folks on this list is a legitimate place to block "rogue" APs, >>> what makes those SSIDs, "yours"? Just because they were used first >>> by the enterprise? That doesn't seem to hold water in an unlicensed >>> environment to me at all. >> >> Pretty much... Here's why... >> >> If you are using an SSID in an area, anyone else using the same SSID >> later is causing harmful interference to your network. It's a >> first-come-first-serve situation. Just like amateur radio spectrum... >> If you're using a frequency to carry on a conversation with someone, >> other hams have an obligation not to interfere with your conversation >> (except in an emergency). It's a bit more complicated there, because >> you're obliged to reasonably accommodate others wishing to use the >> frequency, but in the case of SSIDs, there's no such requirement. >> >> Now, if I start using SSID XYZ in building 1 and someone else is >> using it in building 3 and the two coverage zones don't overlap, I'm >> not entitled to extend my XYZ SSID into building 3 when I rent space >> there, because someone else is using it in that location first. > > So your position is that if I start using Starbuck's SSID in a location > where there is no Starbuck, and they layer move in to that building, > I'm entitled to compel them to not use their SSID? It isn't "Starbuck's SSID". There are no ownership rights or registrations of SSIDs for unlicensed wireless networks. So, under the existing regulatory framework, whoever arrived last is the one causing "harmful interference". > >> I can only extend my XYZ coverage zone so far as there are no >> competing XYZ SSIDs in the locations I'm expanding in to. > > Is ther FCC guidance on this, or is this "Regulations As Interpreted By > Owen"? This is many FCC responses to various part 15 interference complaints as interpreted by Owen. >> Depends on whether you were the first one using the SSID in a >> particular location or not. >> >> Sure, this can get ambiguous and difficult to prove, but the reality >> is that most cases are pretty clear cut and it's usually not hard to >> tell who is the interloper on a given SSID. > > It's usually easy to tell, but I doubt the FCC would find it relevant. > > There's a lot of amateur lawyering ogain on in this thread, in an area > where there's a lot of ambiguity. We don't even know for sure that > what Marriott did is illegal -- all we know is that the FCC asserted it > was and Mariott decided to settle rather than litigate the matter. And > that was an extreme case -- Marriott was making transmissions for the > *sole purpose of preventing others from using the spectrum*. I don't see a lot of ambiguity in a plain text reading of part 15. Could you please read part 15 and tell me what you think is ambiguous? Owen > > -- Brett From mike at mtcc.com Sun Oct 5 06:23:21 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 04 Oct 2014 23:23:21 -0700 Subject: Marriott wifi blocking In-Reply-To: <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> Message-ID: <5430E3D9.3010900@mtcc.com> On 10/04/2014 11:13 PM, Owen DeLong wrote: > Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. > > Further, you seem to assume a level of control over client behavior that is rare in my experience. > > Owen > I this particular case, I think that enterprise could go a very long way to driving a solution through standards and deployment. They, after all, call the shots of who does and who doesn't get over the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. Assuming that there's the perception that this is a big enough problem, of course. Mike From owen at delong.com Sun Oct 5 06:23:11 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Oct 2014 23:23:11 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> Message-ID: Perhaps. I admit that trademark would be a novel approach that might succeed. Of course if I put a satire of Starbucks up on the captive portal, do I qualify under the fair use doctrine for satire? I think in most cases, people are able to be adults and work it out reasonably without involving the FCC or the PTO. Owen > On Oct 4, 2014, at 19:04, Matthew Petach wrote: > > On Sat, Oct 4, 2014 at 5:58 PM, Brett Frankenberger > wrote: > >> ... >> >> So your position is that if I start using Starbuck's SSID in a location >> where there is no Starbuck, and they layer move in to that building, >> I'm entitled to compel them to not use their SSID? > > This would be why commercial entities > often use their trademark identifiers > as part of the SSID. You can compel > them (briefly) not to use the SSID, until > they sue you for trademark infringement > and serve cease-and-desist orders against > you for unlicensed and unauthorized use > of the Starbucks name. Totally separate > realm of enforcement, and in many ways > far more effective. > > Matt From larrysheldon at cox.net Sun Oct 5 13:04:24 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sun, 05 Oct 2014 08:04:24 -0500 Subject: Marriott wifi blocking In-Reply-To: References: Message-ID: <543141D8.8030104@cox.net> On 10/4/2014 12:23, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Majdi S. Abbas" > >> I've seen this in a few places, but if anyone encounters similar >> behavior, I suggest the following: >> >> - Document the incident. >> - Identify the make and model of the access point, or >> controller, and be sure to pass along this information to >> the FCC's OET: http://transition.fcc.gov/oet/ >> >> Vendors really need to start losing their US device certification >> for devices that include advertised features that violate US law. It >> would put a stop to this sort of thing pretty quickly. > > Majdi makes an excellent point, but I want to clarify it, so no one misses > the important subtext: > > It is OK for an enterprise wifi system to make this sort of attack *on rogue > APs which are trying to pretend to be part of it (same ESSID). > > It is NOT OK for an enterprise wifi system to make this sort of attack > on APs which *are not trying to pretend to be part of it* (we'll call this > The Marriott Attack from now on, right?) > > Rogue AP prevention is a *useful* feature in enterprise wifi systems... > but *that isn't what Marriott was doing*. I can agree that prevention of foreign attachments to a net work is morally OK. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From chris.dye at paragon.net Sun Oct 5 15:47:09 2014 From: chris.dye at paragon.net (Christopher Dye) Date: Sun, 5 Oct 2014 15:47:09 +0000 Subject: Equinix Sales In-Reply-To: References: Message-ID: Equinix sales is broken down by region. Where are you looking to go? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson Sent: Saturday, October 04, 2014 8:28 PM To: Daniel Corbe; nanog at nanog.org Subject: Re: Equinix Sales I have a contact. I ill dig it up. On 10/3/14, 10:33 AM, "Daniel Corbe" wrote: > >Equinix Sales seem impossible to reach. Should I just give up and go >through a sales agent or can someone from Equinix sales contact me >off-list? > From patrick at ianai.net Sun Oct 5 18:41:11 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 5 Oct 2014 14:41:11 -0400 Subject: FCC delays Comcast / TWC merger 180 days Message-ID: <9888446E-1304-4FBD-B865-44FFDA795915@ianai.net> Seems to be both on-topic, and timely, given the start of NANOG62 is tomorrow (or today for some). As I mentioned elsewhere, if the FCC asked both companies to provide info and both companies did not provide the info, delaying the merger 180 days is actually a pretty minor penalty. When I don't give the gov't what they want, I usually get a far harsher punishment than "no problem, we'll give you more time". -- TTFN, patrick From fw at deneb.enyo.de Sun Oct 5 19:57:05 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 05 Oct 2014 21:57:05 +0200 Subject: Marriott wifi blocking In-Reply-To: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Sat, 4 Oct 2014 13:23:02 -0400 (EDT)") References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> Message-ID: <87tx3igui6.fsf@mid.deneb.enyo.de> * Jay Ashworth: > It is OK for an enterprise wifi system to make this sort of attack > *on rogue APs which are trying to pretend to be part of it (same > ESSID). What if the ESSID is "Free Internet", or if the network is completely open? Does it change things if you have data that shows your customers can be duped even by networks with a non-colliding ESSID? From jra at baylink.com Sun Oct 5 20:01:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 05 Oct 2014 16:01:05 -0400 Subject: Marriott wifi blocking In-Reply-To: <87tx3igui6.fsf@mid.deneb.enyo.de> References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> <87tx3igui6.fsf@mid.deneb.enyo.de> Message-ID: <48f64d5f-622c-4fd9-b0bc-b5585951cc4b@email.android.com> Well now, Florian, there you lead me into deep water. I am inclined to say that that circumstance would fall into the category of "things you might have a valid reason to want to do, but which the regulations might prevent you from doing even if they are drawn thoughtfully." Myself, I am inclined to think that you have a right to try to protect your users of your ESSID network from people pretending to be it, but that you probably don't have a right to try to protect people who are too stupid to be attaching to the right thing. And yes, I realize that if a Windows machine for example tries to attach to a network and gets knocked off it might move down its list and the user might not notice. If your network is this much of an attack target, make sure your building is a Faraday cage, and then you can knock off anything you like. In the final analysis, what will really happen in a business environment, is likely just that your warning system will warn you, and you will walk around with an AirCheck and find the rogue AP and unplug it and beat over the head with it whomever set it up. :-) On October 5, 2014 3:57:05 PM EDT, Florian Weimer wrote: >* Jay Ashworth: > >> It is OK for an enterprise wifi system to make this sort of attack >> *on rogue APs which are trying to pretend to be part of it (same >> ESSID). > >What if the ESSID is "Free Internet", or if the network is completely >open? Does it change things if you have data that shows your >customers can be duped even by networks with a non-colliding ESSID? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Sun Oct 5 21:23:47 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 5 Oct 2014 17:23:47 -0400 (EDT) Subject: Marriott wifi blocking In-Reply-To: Message-ID: <28776170.4285.1412544227890.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > This would be why commercial entities > often use their trademark identifiers > as part of the SSID. You can compel > them (briefly) not to use the SSID, until > they sue you for trademark infringement > and serve cease-and-desist orders against > you for unlicensed and unauthorized use > of the Starbucks name. Totally separate > realm of enforcement, and in many ways > far more effective. Though this requires you to buy the argument that the use of a wordmark *in an address of some time* is infringing under the terms of the Lanham Act, which is a point on which I don't believe there's presently any case law, and which I think would be a difficult argument to prosecute against a properly defended plaintiff. Just *using a word* that someone has registered as a wordmark is not inherently infringement, or Ford City PA would be in serious trouble. The Lanham Act is *quite* clear on what is an infringing use, and I don't myself believe the posited case qualifies. Cheers, -- jr 'IANAL' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From srikanth at gatech.edu Sun Oct 5 22:43:31 2014 From: srikanth at gatech.edu (Srikanth Sundaresan) Date: Sun, 5 Oct 2014 15:43:31 -0700 Subject: Netalyzr Android: call for volunteers Message-ID: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> Hi all, Netalyzr is a free network measurement and debugging app developed by the International Computer Science Institute, Berkeley. It is designed to check for a wide range of network problems and neutrality violations, including unadvertised port filtering, DNS wildcarding, and hidden proxy servers. Our browser applet has more than a million runs. Netalyzr for Android was released in October 2013. We are happy to announce a new release that has new tests for better middlebox probing and a better UI. If you're interested, you can download and run the app from Google Play [1]. If you already have the app, please consider updating and re-running it - it would be very helpful for us to capture updates regarding how the mobile Internet is evolving. Oh and: please consider watching our talk at NANOG 62 on Monday [2]! Thanks, The Netalyzr Team. [1] https://play.google.com/store/apps/details?id=edu.berkeley.icsi.netalyzr.android&hl=en [2] https://www.nanog.org/meetings/abstract?id=2419 From rbf+nanog at panix.com Sun Oct 5 23:13:13 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 5 Oct 2014 18:13:13 -0500 Subject: Marriott wifi blocking In-Reply-To: <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> Message-ID: <20141005231312.GA18326@panix.com> On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: > > > There's a lot of amateur lawyering ogain on in this thread, in an area > > where there's a lot of ambiguity. We don't even know for sure that > > what Marriott did is illegal -- all we know is that the FCC asserted it > > was and Mariott decided to settle rather than litigate the matter. And > > that was an extreme case -- Marriott was making transmissions for the > > *sole purpose of preventing others from using the spectrum*. > > I don't see a lot of ambiguity in a plain text reading of part 15. > Could you please read part 15 and tell me what you think is > ambiguous? Marriott was actually accused of violating 47 USC 333: No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government. In cases like the Marriott case, where the sole purpose of the transmission is to interfere with other usage of the transmission, there's not much ambiguity. But other cases aren't clear from the text. For example, you've asserted that if I've been using "ABCD" as my SSID for two years, and then I move, and my new neighbor is already using that, that I have to change. But that if, instead of duplicating my new neighbor's pre-existing SSID, I operate with a different SSID but on the same channel, I don't have to change. I'm not saying your position is wrong, but it's certainly not clear from the text above that that's where the line is. That's what I meant by ambiguity. (What's your position on a case where someone puts up, say, a continuous carrier point-to-point system on the same channel as an existing WiFi system that is now rendered useless by the p-to-p system that won't share the spectrum? Illegal or Legal? And do you think the text above is unambiguous on that point?) -- Brett From mysidia at gmail.com Sun Oct 5 23:31:46 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 5 Oct 2014 18:31:46 -0500 Subject: Marriott wifi blocking In-Reply-To: <20141005231312.GA18326@panix.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: On Sun, Oct 5, 2014 at 6:13 PM, Brett Frankenberger wrote: > For example, you've asserted that if I've been using "ABCD" as my SSID > for two years, and then I move, and my new neighbor is already using > that, that I have to change. But that if, instead of duplicating my [snip] Actually... I would suggest that it is not entirely clear if you have to change or not. Your conflicting SSID in no way impedes the use of the spectrum, one of you just has to recode your SSID; this is different from setting up a WIPS Rogue AP containment feature to completely block an AP from ever being used. If your SSID happens to conflict with your neighbor's SSID by coincidence, and the SSID is a common name such as Linksys, then this conflict alone probably does not qualify as willful or malicious interference. As the spectrum is unlicensed, neither of you is a licensed station, and neither of you has "priority"; neither of your stations is a primary or secondary user. Both of your stations has to accept the unintended interference in the unlicensed frequencies; it is essentially up to the two of you to either take it upon yourself to change your own SSID, or to negotiate with your neighbor. On the other hand, if you chose a SSID for your AP of "STARBUCKS" and you set this up in proximity to a Starbucks location or selected "[YOURNEIGHBORSCOMPANYNAME]" as your SSID; it would seem to be more evident that any interference that was occuring to their wireless station operation was willful and possibly a malicious attempt to compromise client security. -- -JH From mpalmer at hezmatt.org Mon Oct 6 00:59:59 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 6 Oct 2014 11:59:59 +1100 Subject: large BCP38 compliance testing In-Reply-To: <542EF71A.5020709@pubnix.net> References: <542D9852.3020902@gameservers.com> <20141002224754.GA7606@gsp.org> <20141002225433.59C7720AF55D@rock.dv.isc.org> <20141003151745.GA24228@gsp.org> <542EF71A.5020709@pubnix.net> Message-ID: <20141006005959.GA2406@hezmatt.org> On Fri, Oct 03, 2014 at 03:20:58PM -0400, Alain Hebert wrote: > On the 1st of January 2015: That's quite short notice. Perhaps we could delay it by exactly three months? - Matt From mysidia at gmail.com Mon Oct 6 01:44:49 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 5 Oct 2014 20:44:49 -0500 Subject: large BCP38 compliance testing In-Reply-To: <43245.1412265241@turing-police.cc.vt.edu> References: <43245.1412265241@turing-police.cc.vt.edu> Message-ID: On Thu, Oct 2, 2014 at 10:54 AM, wrote: > The *real* problem isn't the testing. > It's the assumption that you can actually *do* anything useful with this data. > Name-n-shame probably won't get us far - and the way the US works, if there's a At least "name and shame" is something more useful than nothing done. Ideally you would have transit providers and peering exchanges placing "Must implement BCP38" into their peering policy, and then they could use the data to help enforce their peering policies. -- -JH From jhall at futuresouth.us Mon Oct 6 06:50:26 2014 From: jhall at futuresouth.us (Jonathan Hall) Date: Mon, 6 Oct 2014 06:50:26 +0000 Subject: Shellshock vulnerability research leads to WHAT?! Message-ID: While a little off-topic for the NANOG list, I figured some of you may want to know about this. I started researching and testing this vulnerability the day it was released, and once I started researching its usage/exploitation in the wild, I identified that a few major sites were actually compromised using the vulnerability - Yahoo! being one in particular. Tripod/Lycos and WinZip.com were also compromised. Yahoo! reached out and gave me a response, albeit a very weak one, only after the FBI, media and CEO Marissa Mayers was contacted... WinZip patched their boxes and didn't bother responding or notifying me that they got it done. Please do excuse the scattered nature of the email sent to Marissa Mayers @ Yahoo! - there were other correspondences that are currently being kept private, and at the time that I wrote that one, I had been awake for roughly 48 hours and was fueled on caffeine and nicotine. The chances are highly likely that Yahoo! is going to do their best at keeping this quiet and not release any information or details on this, and I figured that some of at are undoubtedly just as at risk from this as anyone else. Please see the rest of everything related to this at http://www.futuresouth.us/yahoo_hacked.html And http://www.futuresouth.us/yahoo_response.jpg for their initial response. Non-authoritative answer: Name: dip4.gq1.yahoo.com Address: 63.250.204.25 Non-authoritative answer: Name: api118.sports.gq1.yahoo.com Address: 10.212.240.43 These are the two servers that were 100% positively identified thus far as being compromised by both me and Yahoo!, with dip4.gq1.yahoo.com being the initial point of entry via Shellshock. Jonathan D. Hall Future South Technologies www.futuresouth.us (504) 470-3748 - [main] (504) 232-3306 - [cell] Life is a dream for the wise, a game for the fool, a comedy for the rich and a tragedy for the poor. From jgreco at ns.sol.net Mon Oct 6 10:21:10 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 6 Oct 2014 05:21:10 -0500 (CDT) Subject: Marriott wifi blocking In-Reply-To: <20141005231312.GA18326@panix.com> Message-ID: <201410061021.s96ALA1I082478@aurora.sol.net> > On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: > > > There's a lot of amateur lawyering ogain on in this thread, in an area > > > where there's a lot of ambiguity. We don't even know for sure that > > > what Marriott did is illegal -- all we know is that the FCC asserted it > > > was and Mariott decided to settle rather than litigate the matter. And > > > that was an extreme case -- Marriott was making transmissions for the > > > *sole purpose of preventing others from using the spectrum*. > > > > I don't see a lot of ambiguity in a plain text reading of part 15. > > Could you please read part 15 and tell me what you think is > > ambiguous? > > Marriott was actually accused of violating 47 USC 333: > No person shall willfully or maliciously interfere with or cause > interference to any radio communications of any station licensed or > authorized by or under this chapter or operated by the United States > Government. > > In cases like the Marriott case, where the sole purpose of the > transmission is to interfere with other usage of the transmission, > there's not much ambiguity. But other cases aren't clear from the > text. > > For example, you've asserted that if I've been using "ABCD" as my SSID > for two years, and then I move, and my new neighbor is already using > that, that I have to change. But that if, instead of duplicating my > new neighbor's pre-existing SSID, I operate with a different SSID but > on the same channel, I don't have to change. I'm not saying your > position is wrong, but it's certainly not clear from the text above > that that's where the line is. That's what I meant by ambiguity. I've watched this discussion with much amusement. In a manner similar to our legal system, where a lot of the law is actually defined by what is commonly called "case law", most of the non-radio geeks here are talking about radios and spectrum as though all of this represents some sort of new problem, when in fact the agency tasked with handling it is older than any of us. > (What's your position on a case where someone puts up, say, a > continuous carrier point-to-point system on the same channel as an > existing WiFi system that is now rendered useless by the p-to-p system > that won't share the spectrum? Illegal or Legal? And do you think the > text above is unambiguous on that point?) It doesn't matter if you think your quoted text on this point is ambiguous. The fact of the matter is that decades of policy are that the FCC decided many years ago that you cannot go onto shared, unlicensed spectrum with a powerful transmitter and hold the mic open with the intent to disrupt the legitimate communications traffic of others on that channel. This logically derives fairly straightforwardly from the quoted text, and the fact that wifi deauth interference is merely a packet-pushing variant of this isn't really hard for the average person to extrapolate. But they also have decades of experience with other aspects of more subtle radio shenanigans, and they have the authority to sort it all out, so what we should really be hoping for is that the FCC doesn't do something onerous like mandate registration of access point MAC's and SSID's if and when it gets to a point where it is considered a true problem. That could well be the regulatory "solution" to your ABCD problem, but it would be a heavyhanded fix to a minor problem. ... 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 a.harrowell at gmail.com Mon Oct 6 10:42:52 2014 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 6 Oct 2014 11:42:52 +0100 Subject: Marriott wifi blocking In-Reply-To: References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004030408.GE1424@bamboo.slabnet.com> Message-ID: On Sat, Oct 4, 2014 at 4:32 AM, Jay Ashworth wrote: > Hugo, I still don't think that you have quite made it to the distinction that we are looking for here. > > In the case of the hotel, we are talking about an access point that connects via 4G to a cellular carrier. An access point that attempts to create its own network for the subscribers devices. A network disjoint from the network provided by the hotel or its contractor. To put it another way, if you plugged a USB cable into the 4G device and the other end into a laptop, and a hotel manager appeared with a big pair of scissors and cut through it, in an effort to make you buy WLAN service from the hotel, nobody would think this either legal or reasonable. Why should it be more acceptable because you used radio? What about IrDA, if you're a technical masochist? > > This is a different case from the circumstance in a business office where equipment is deployed to prevent someone from walking in with an access point /which pretends to be part of the network which the office runs./ > > In the latter case, the security hardware is justified in deassociating people from the rogue access point, /because it is pretending to be part of a network it is not authorized to be part of/. > > In the Marriott case, that is not the circumstance. The networks which the deauth probes are being aimed at are networks which are advertising themselves as being /separate from the network operated by the hotel/, and this is the distinction that makes Marriott's behavior is unacceptable. > > (In my opinion; I am NOT a lawyer. If following my advice breaks something, you get to keep both pieces.) > > On October 3, 2014 11:04:08 PM EDT, Hugo Slabbert wrote: >>On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman >>wrote: >> >>>On 10/3/14 7:25 PM, "Hugo Slabbert" wrote: >>> >>>>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman >>>>wrote: >>>> >>>>>IANAL, but I believe they are. State laws may also apply (e.g. >>>>>California >>>>>Code - Section 502). In California, it is illegal to "knowingly and >>>>>without permission disrupts or causes the disruption of computer >>services >>>>>or denies or causes the denial of computer services to an authorized >>user >>>>>of a computer, computer system, or computer network." Blocking >>access to >>>>>somebody's personal hot spot most likely qualifies. >>>> >>>>My guess would be that the hotel or other organizations using the >>>>blocking tech would probably just say the users/admin of the rogue >>APs >>>>are not authorized users as setting up said AP would probably be in >>>>contravention of the AUP of the hotel/org network. >>> >>>They can say anything they want, it does not make it legal. >>> >>>There's no such thing as a "rogue" AP in this context. I can run an >>>access point almost anywhere I want (there are limits established by >>the >>>FCC in some areas) and it does not matter who owns the land >>underneath. >>>They have no authority to decide whether or not my access point is >>>"authorized." They can certainly refuse to connect me to their wired >>>network; and they can disconnect me if they decide I am making >>>inappropriate use of their network -- but they have no legal authority >>to >>>interfere with my wireless transmissions on my own network (be it my >>>personal hotspot, WiFi router, etc.). FWIW, the same is true in >>almost >>>all corporate environments as well. >> >>Thanks; I think that's the distinction I was looking for here. By >>spoofing deauth, the org is actively/knowingly participating on *my >>network* and causing harm to it without necessarily having proof that >>*my network* is in any way attached to *their network*. The assumption >> >>in the hotel case is likely that the WLANs of the "rogue" APs they're >>targeting are attached to their wired network and are attempts to >>extend >>that wireless network without authorization (and that's probably >>generally a pretty safe assumption), but that doesn't forgive causing >>harm to that WLAN. There's no reason they can't cut off the wired port >> >>of the AP if it is connected to the org's network as that's their >>attachment point and their call, but spoofed deauth stuff does seem to >>be out of bounds. >> >>I'm not clear on whether it runs afoul of FCC regs as it's not RF >>interference directly but rather an (ab)use of higher layer control >>mechanisms operating on that spectrum, but it probably does run afoul >>of >>most "thou shalt not harm other networks" legislation like the >>California example. >> >>> >>>/Mike >>> >>> >> >>-- >>Hugo > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From valeriu at roedu.net Mon Oct 6 10:57:46 2014 From: valeriu at roedu.net (Valeriu Vraciu) Date: Mon, 06 Oct 2014 13:57:46 +0300 Subject: Level3 contact Message-ID: <543275AA.60606@roedu.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, If someone from Level3 (Europe) with core access is here and willing to assist, please can you contact me off-list for routing issues related to AS2614 (RoEduNet) BGP in Bucharest, RO ? Thanks. - -- Valeriu Vraciu RoEduNet (AS2614) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQydaoACgkQncI+CatY949o0QCaAxLGeRzBcOMrxlQaSy8oBKeS swAAn3lkwk+Z66lRnzz4Q8U9zdGoe98V =/mSr -----END PGP SIGNATURE----- From david at cantrell.org.uk Mon Oct 6 11:24:17 2014 From: david at cantrell.org.uk (David Cantrell) Date: Mon, 6 Oct 2014 12:24:17 +0100 Subject: Marriott wifi blocking In-Reply-To: <20141004025707.GD1424@bamboo.slabnet.com> References: <32694396.4191.1412380452420.JavaMail.root@benjamin.baylink.com> <20141004022522.GB1424@bamboo.slabnet.com> <20141004025707.GD1424@bamboo.slabnet.com> Message-ID: <20141006112417.GA7992@bytemark.barnyard.co.uk> On Fri, Oct 03, 2014 at 07:57:07PM -0700, Hugo Slabbert wrote: > But it's not a completely discrete network. It is a subset of the > existing network in the most common example of e.g. a WLAN + NAT device > providing access to additional clients, or at least an adjacent network > attached to the existing one. Okay: theoretically a guest could spin up > a hotspot and not attach it to the hotel network at all, but I'm > assuming that's a pretty tiny edge case. I don't think it is. It's common for phones to be able to share their 3G/4G/whatever wossnames with other devices over wifi. And these days you don't even have to pay the telco extra. -- David Cantrell | A machine for turning tea into grumpiness "Cynical" is a word used by the naive to describe the experienced. George Hills, in uknot From Vinny_Abello at Dell.com Mon Oct 6 12:28:11 2014 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Mon, 6 Oct 2014 12:28:11 +0000 Subject: Google Search Contact Message-ID: Sorry for the noise, but can anyone get me in touch with a contact at Google, specifically regarding Google Search? Please reply off-list. Thanks. -Vinny From ahebert at pubnix.net Mon Oct 6 12:32:56 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 06 Oct 2014 08:32:56 -0400 Subject: large BCP38 compliance testing In-Reply-To: <23040140.4187.1412379385016.JavaMail.root@benjamin.baylink.com> References: <23040140.4187.1412379385016.JavaMail.root@benjamin.baylink.com> Message-ID: <54328BF8.3080907@pubnix.net> On 10/03/14 19:36, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Alain Hebert" >> PS: About that uRPF Convo, we could dump all that knowledges into >> lets say... some comprehensive wiki page maybe =D That way when the >> topic arise we could just link to it. > Gee, Alain... > > where would people find a wiki like that? > > Cheers, > -- jra On google maybe... I see someone is already squatting http://www.bcp38.info :( ( /end_of_friday_silliness ) From c at starbs.net Mon Oct 6 12:42:28 2014 From: c at starbs.net (Michael Banks) Date: Mon, 06 Oct 2014 13:42:28 +0100 Subject: Google Search Contact In-Reply-To: References: Message-ID: <20141006124228.5927058.95528.577@starbs.net> I would also appreciate a similar contact regarding search, please contact off list. Thanks. -- Chip e:hi at itschip.com m:+44 (0) 785 752 7096 p:+44 (0) 800 710 1182 w:https://itschip.com   Original Message   From: Vinny_Abello at Dell.com Sent: Monday, 6 October 2014 13:29 To: nanog at nanog.org Subject: Google Search Contact‎ Sorry for the noise, but can anyone get me in touch with a contact at Google, specifically regarding Google Search? Please reply off-list. Thanks. -Vinny From emile.aben at ripe.net Mon Oct 6 14:32:42 2014 From: emile.aben at ripe.net (Emile Aben) Date: Mon, 06 Oct 2014 16:32:42 +0200 Subject: visibility/reachability of longer-than-/24 IPv4 prefixes Message-ID: <5432A80A.9080004@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, In a cooperation between the RIPE NCC and ARIN we investigate the visibility/reachability of longer-than-/24 prefixes out of ARIN's 23.128/10 IPv4 address block. This part of ARIN policy (https://www.arin.net/policy/nrpm.html#four10) elicited much discussion on NANOG earlier this year, so we decided to try and measure the current state of the network with regards to longer-than-/24 IPv4 prefixes. We've now published a RIPE Labs article with initial analysis results: https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes Spoiler: the longer-than-/24 prefixes are not very visible/reachable. Having route-objects improves visibility/reachability, but only a little bit. cheers, Emile Aben RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUMqgKAAoJEKxthF6wloMO9LUQAITnqRgmI0G7yD7Vv7E30wpu W2YwXV6nP3ssq7XDE/ByqmXzDycS9Iu3/h+IK9Th5KqeCJIfGsyIDGvD1P4QCswd vyTA0a6iND03cX1JbuuA6mQZyf7oeIsFeCUzxjTBBTU0K2O62ngrnr74K6LCFNx9 2k4gSyyn1BJ4FQpgXgRnaADrcKR9pvYXa92HRCXZwXl7hBsbo213u79CNc8iF6nH einYXqifNzxjoNtUqHKDPFX93t5nHSUGJBqV2Xe/Lr89aGSGkXdlGZqd1GhFdaPf O0gryNJWg2r3maM0THte/UYIzFKaVS71f5eZj+blj1eb9mIxLcVPtIdh8rB7JJ8r Pyi3yOjBdusntGY3dfsG4pYV80og2yn8AIVQde0hBEoreESjqGzMv74ZO7avXtZ6 K3c48uS/sL49EXafDgiinJ+9YblqCd4+cw0YockbCl5WFSZGRzth1R1J7UESgVH6 gk0yO9BzmHcuNLcxJVfRJJV4NkEJ+sVAuFwFWmushPjQWm1PGLDCVBhRvynOxvOK eqff9Rs0SkQpJ9gN05HnaWcb87gjjTFKWxZ8l2xbZo4JkAgRSvMLkrthviSvN2PX 7DhGlC+hlq4mpR/y1YwiEF4oMFkH9feni4P0lFfbLNR2I72MyAv0lIu9hawIUpwn ryDIUKXZOvPifOAs/5PA =vaXm -----END PGP SIGNATURE----- From owen at delong.com Mon Oct 6 14:37:05 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Oct 2014 07:37:05 -0700 Subject: Marriott wifi blocking In-Reply-To: <5430E3D9.3010900@mtcc.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> Message-ID: <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> On Oct 4, 2014, at 11:23 PM, Michael Thomas wrote: > On 10/04/2014 11:13 PM, Owen DeLong wrote: >> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. >> >> Further, you seem to assume a level of control over client behavior that is rare in my experience. >> >> Owen >> > > I this particular case, I think that enterprise could go a very long way to driving a solution through > standards and deployment. They, after all, call the shots of who does and who doesn't get over > the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. Not sure what you mean by corpro-drawbridge in this context. Some corporations exercise extreme control over their clients. They are the exception, not the rule. The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc. > Assuming that there's the perception that this is a big enough problem, of course. Not sure. The issue you seem to be talking about seems somewhat orthogonal to the original topic of the thread, so I”m not sure going too deep into it in this forum is appropriate. Owen From owen at delong.com Mon Oct 6 14:44:33 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Oct 2014 07:44:33 -0700 Subject: Marriott wifi blocking In-Reply-To: <87tx3igui6.fsf@mid.deneb.enyo.de> References: <9205121.4265.1412443382213.JavaMail.root@benjamin.baylink.com> <87tx3igui6.fsf@mid.deneb.enyo.de> Message-ID: On Oct 5, 2014, at 12:57 PM, Florian Weimer wrote: > * Jay Ashworth: > >> It is OK for an enterprise wifi system to make this sort of attack >> *on rogue APs which are trying to pretend to be part of it (same >> ESSID). > > What if the ESSID is "Free Internet", or if the network is completely > open? Does it change things if you have data that shows your > customers can be duped even by networks with a non-colliding ESSID? To the best of my knowledge, not under the current regulatory framework. It’s not considered harmful interference if the SSID isn’t conflicting. The fact that your users are stupid isn’t license for you to attack someone else’s network. Owen From mirkomaffioli at gmail.com Mon Oct 6 13:28:19 2014 From: mirkomaffioli at gmail.com (Mirko Maffioli) Date: Mon, 6 Oct 2014 15:28:19 +0200 Subject: VDSL concentrator Message-ID: I'm searching for a low price VDSL DSLAM like e.g. the Patton FF3210P. I need to redistribute the connectivity to customers inside a large campus but i don't need any particular additional service. Do you have any advice? Thanks! Mirko From jschiel at flowtools.net Mon Oct 6 15:04:55 2014 From: jschiel at flowtools.net (John Schiel) Date: Mon, 06 Oct 2014 09:04:55 -0600 Subject: Marriott wifi blocking In-Reply-To: <20141003222627.GA1424@bamboo.slabnet.com> References: <9BDFAB0562768B4AA45C6317464336602ED623FF@GO001WIN393.ad.shopko.com> <542F13E2.7060407@stargate.ca> <542F1CB1.4030309@flowtools.net> <20141003222627.GA1424@bamboo.slabnet.com> Message-ID: <5432AF97.1010301@flowtools.net> On 10/03/2014 04:26 PM, Hugo Slabbert wrote: > On Fri 2014-Oct-03 16:01:21 -0600, John Schiel > wrote: > >> >> On 10/03/2014 03:23 PM, Keenan Tims wrote: >>>> The question here is what is authorized and what is not. Was this >>>> to protect their network from rogues, or protect revenue from >>>> captive customers. >>> I can't imagine that any 'AP-squashing' packets are ever authorized, >>> outside of a lab. The wireless spectrum is shared by all, regardless of >>> physical locality. Because it's your building doesn't mean you own the >>> spectrum. >> >> +1 >> >>> >>> My reading of this is that these features are illegal, period. Rogue AP >>> detection is one thing, and disabling them via network or >>> "administrative" (ie. eject the guest) means would be fine, but >>> interfering with the wireless is not acceptable per the FCC >>> regulations. >>> >>> Seems like common sense to me. If the FCC considers this >>> 'interference', >>> which it apparently does, then devices MUST NOT intentionally >>> interfere. >> >> I would expect interfering for defensive purposes **only** would be >> acceptable. > > What constitutes "defensive purposes"? Whoa, lots of replies this weekend. I haven't made my way through all of them but the point was to try and protect your network from an offensive device. It seems though, if you are law abiding and follow the FCC rules, you **cannot** protect yourself very well using the wireless spectrum. Need to do some more reading I guess. --John > >> >> --John >> >>> >>> K >> > From mike at mtcc.com Mon Oct 6 15:06:56 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 06 Oct 2014 08:06:56 -0700 Subject: Marriott wifi blocking In-Reply-To: <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> Message-ID: <5432B010.1070302@mtcc.com> On 10/06/2014 07:37 AM, Owen DeLong wrote: > On Oct 4, 2014, at 11:23 PM, Michael Thomas wrote: > >> On 10/04/2014 11:13 PM, Owen DeLong wrote: >>> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. >>> >>> Further, you seem to assume a level of control over client behavior that is rare in my experience. >>> >>> Owen >>> >> I this particular case, I think that enterprise could go a very long way to driving a solution through >> standards and deployment. They, after all, call the shots of who does and who doesn't get over >> the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. > Not sure what you mean by corpro-drawbridge in this context. > > Some corporations exercise extreme control over their clients. They are the exception, not the rule. > > The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc. > > It means that they can exercise control of what they allow on their corporate network, byod or not. Nobody would allow a WEP-only wireless device on their network these days, so it's not hard to imagine that if a standard for authenticating AP's became available and enterprises went to the effort to upgrade their AP kit, they could reasonably say "use a client that supports this, or you must vpn in". That's a much better outcome than quibbling about squatter's rights, blah blah blah. Mike From owen at delong.com Mon Oct 6 15:41:57 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Oct 2014 08:41:57 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: On Oct 5, 2014, at 4:31 PM, Jimmy Hess wrote: > On Sun, Oct 5, 2014 at 6:13 PM, Brett Frankenberger wrote: >> For example, you've asserted that if I've been using "ABCD" as my SSID >> for two years, and then I move, and my new neighbor is already using >> that, that I have to change. But that if, instead of duplicating my > [snip] > > Actually... I would suggest that it is not entirely clear if you have > to change or not. Your conflicting SSID in no way impedes the use of > the spectrum, one of you just has to recode your SSID; this is > different from setting up a WIPS Rogue AP containment feature to > completely block an AP from ever being used. If your SSID happens > to conflict with your neighbor's SSID by coincidence, and the SSID is > a common name such as Linksys, then this conflict alone probably does > not qualify as willful or malicious interference. Right… You probably don’t face the issues under 47CFR333, but you’ve still got a 47CFR15.5 problem of harmful interference. > As the spectrum is unlicensed, neither of you is a licensed station, and > neither of you has "priority"; neither of your stations is a primary > or secondary user. Both of your stations has to accept the > unintended interference in the unlicensed frequencies; it is > essentially up to the two of you to either take it upon yourself to > change your own SSID, or to negotiate with your neighbor. Actually, in multiple situations, the FCC has stated that you are responsible when deploying a new unlicensed transmitter to insure that it is deployed in such a way that it will not cause harmful interference to existing operations. Using the same SSID of someone else who is already present would, IMHO, meet the test of “causing harmful interference”. > On the other hand, if you chose a SSID for your AP of "STARBUCKS" and > you set this up in proximity to a Starbucks location or selected > "[YOURNEIGHBORSCOMPANYNAME]" as your SSID; it would seem to be more > evident that any interference that was occuring to their wireless > station operation was willful and possibly a malicious attempt to > compromise client security. Willful and malicious only comes into play if you’re looking to prosecute under 333. Any harmful interference is still a problem under 15.5. Owen From jcurran at arin.net Mon Oct 6 16:51:56 2014 From: jcurran at arin.net (John Curran) Date: Mon, 6 Oct 2014 16:51:56 +0000 Subject: Final Reminder - ARIN Public Policy Consultation at NANOG 62 Baltimore References: <542D88D9.3030203@arin.net> Message-ID: <10BB6202-AD6C-405A-A0EC-E3E709503DA8@corp.arin.net> NANOG 62 Baltimore Attendees (and Remote Participants) - Starting at 9 AM tomorrow, there will be an ARIN Public Policy Consultation in the Chesapeake AB room. A list of the draft policies that will be discussed is attached (and available online on the event Agenda page.) This a great opportunity for the network operator community to feedback on these proposed policies, particularly if you are not staying for the ARIN meeting which follows NANOG 62 this week. All NANOG attendees are encouraged to participate, as adopted policies will affect that administration of number resources in the region. See you tomorrow morning! /John p.s. If you are not on-site in Baltimore, you can still remotely participate in the ARIN Public Policy Consultation; please preregister via the "Register" link at the bottom of the Agenda page - NANOG Folks - There are a number of proposed changes to number resource policy in the ARIN region, and you'll have two opportunities to discuss these proposals next week in Baltimore (or remotely, as you prefer) The Public Policy Consultation within NANOG takes place on Tuesday morning from 9 to 1 PM; everyone is welcome (although preregistration is required if you are not already registered for NANOG.) The ARIN 34 Meeting will follow NANOG on Thursday and Friday; we will have discussions of policy changes, as well as ARIN fee schedule, changes in the stewardship of the IANA functions, and more. Information on ARIN registration is also included in the attached message. I look forward to seeing everyone in Baltimore! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] The PPC @ NANOG 62 & ARIN 34 Will Be Here Soon – Get Ready! Date: October 2, 2014 at 1:18:17 PM EDT To: > Next week will be busy! With the Public Policy Consultation (PPC) at NANOG 62 and ARIN 34 Public Policy and Members Meeting, we will be in the thick of important community discussions on ten policy proposals. * Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements * Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] * Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers * Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers * Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification * Draft Policy ARIN-2014-1: Out of Region Use * Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update * Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate * Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments * Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization Whether you plan to join us online or in-person, we want to make sure you are ready. To help you prepare for the meeting, ARIN has published all of the meeting materials online for you to review or download before the meeting begins. Just visit: https://www.arin.net/ppc_materials or https://www.arin.net/ARIN34_materials Copies of the presentations of the meetings will also be posted at the above URLs once the meeting has started, as they are available. We hope to see you in Baltimore, but if you are unable to join us in person, be sure to keep up with us by participating remotely! View the agenda, learn more about remote participation, and register today by visiting: The PPC at NANOG 62: https://www.arin.net/ppcnanog62 ARIN 34: https://www.arin.net/ARIN34 Please contact us at info at arin.net if you have any questions. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From rsk at gsp.org Mon Oct 6 17:11:33 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 6 Oct 2014 13:11:33 -0400 Subject: A few Baltimore tips for this week Message-ID: <20141006171133.GA6062@gsp.org> Restaurants worth visiting: the Waterfront Kitchen (pricey, worth it, harbor views), The Helmand (Afghan, delicious, charming hosts), McCormick & Schmick's (seafood, harbor views), The Black Olive (Greek), B&O Brasserie (great cocktails too), Sotto Sopra (Italian), Da Mimmo's (Italian) Restaurants with good beer: The Brewer's Art (home of Resurrection Ale), The Alewife (one dining room is a former bank vault), Heavy Seas Ale House (extraaaaarrrrdinary beers, matey) What you should try: crabs (steamed, soft-shell, crabcakes or any other way you can get them) seasoned (of course) with Old Bay Places to go in your copious free time: American Visionary Art Museum, the National Aquarium, Fort McHenry The Charm City Circulator is a free bus service that runs on various routes downtown. Water taxis (not free) run across the harbor. Do not be confused if someone says "Welcome to Bawlmer Merlund, hon": you're in the correct city. Fells Point, Canton, the Inner Harbor and Federal Hill are all reasonably safe. Travel in groups at night and/or take a cab if it's late. Stay the hell away from North Avenue unless you want to be an extra in The Wire. Berger Cookies are really bad for your diet and you definitely want some. Don't fall into the harbor, the water quality is...dubious. ---rsk From owen at delong.com Mon Oct 6 17:12:18 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Oct 2014 10:12:18 -0700 Subject: Marriott wifi blocking In-Reply-To: <5432B010.1070302@mtcc.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> Message-ID: <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> On Oct 6, 2014, at 8:06 AM, Michael Thomas wrote: > On 10/06/2014 07:37 AM, Owen DeLong wrote: >> On Oct 4, 2014, at 11:23 PM, Michael Thomas wrote: >> >>> On 10/04/2014 11:13 PM, Owen DeLong wrote: >>>> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. >>>> >>>> Further, you seem to assume a level of control over client behavior that is rare in my experience. >>>> >>>> Owen >>>> >>> I this particular case, I think that enterprise could go a very long way to driving a solution through >>> standards and deployment. They, after all, call the shots of who does and who doesn't get over >>> the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. >> Not sure what you mean by corpro-drawbridge in this context. >> >> Some corporations exercise extreme control over their clients. They are the exception, not the rule. >> >> The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc. >> >> > > It means that they can exercise control of what they allow on their corporate network, byod or not. Nobody > would allow a WEP-only wireless device on their network these days, so it's not hard to imagine that if a standard > for authenticating AP's became available and enterprises went to the effort to upgrade their AP kit, they could > reasonably say "use a client that supports this, or you must vpn in”. I think most environments already support this to some extent in terms of the APs participating in the controller framework and 802.1x authentication. However, that doesn’t cover the guy that brings a linksys in and plugs it into his wired port. I think the only solution for those is detection followed by blocking the wired port until resolution. Most companies I have worked with that took the time to think this through simply made it an instant firing offense for anyone to plug in an unauthorized WAP to the corporate wired network, problem solved. > That's a much better outcome than quibbling about squatter's rights, blah blah blah. To the extent that such is a feasible solution, I think it was long since done. That’s got nothing to do with what this discussion was about, however, you’ve warped it into a completely different problem space. Owen From mike at mtcc.com Mon Oct 6 17:32:09 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 06 Oct 2014 10:32:09 -0700 Subject: Marriott wifi blocking In-Reply-To: <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> Message-ID: <5432D219.5050701@mtcc.com> On 10/06/2014 10:12 AM, Owen DeLong wrote: > On Oct 6, 2014, at 8:06 AM, Michael Thomas wrote: > >> On 10/06/2014 07:37 AM, Owen DeLong wrote: >>> On Oct 4, 2014, at 11:23 PM, Michael Thomas wrote: >>> >>>> On 10/04/2014 11:13 PM, Owen DeLong wrote: >>>>> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. >>>>> >>>>> Further, you seem to assume a level of control over client behavior that is rare in my experience. >>>>> >>>>> Owen >>>>> >>>> I this particular case, I think that enterprise could go a very long way to driving a solution through >>>> standards and deployment. They, after all, call the shots of who does and who doesn't get over >>>> the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. >>> Not sure what you mean by corpro-drawbridge in this context. >>> >>> Some corporations exercise extreme control over their clients. They are the exception, not the rule. >>> >>> The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc. >>> >>> >> It means that they can exercise control of what they allow on their corporate network, byod or not. Nobody >> would allow a WEP-only wireless device on their network these days, so it's not hard to imagine that if a standard >> for authenticating AP's became available and enterprises went to the effort to upgrade their AP kit, they could >> reasonably say "use a client that supports this, or you must vpn in”. > I think most environments already support this to some extent in terms of the APs participating in the controller framework and 802.1x authentication. > > However, that doesn’t cover the guy that brings a linksys in and plugs it into his wired port. > > I think the only solution for those is detection followed by blocking the wired port until resolution. If there's strong auth to the AP which enforces which SSID I connect to, who cares about somebody bringing their own AP and fire up an SSID with the same name as $COPROSSID? > Most companies I have worked with that took the time to think this through simply made it an instant firing offense for anyone to plug in an unauthorized WAP to the corporate wired network, problem solved. That's orthogonal to somebody backhauling the AP's traffic to some other (possibly evil) network. > >> That's a much better outcome than quibbling about squatter's rights, blah blah blah. > To the extent that such is a feasible solution, I think it was long since done. That’s got nothing to do with what this discussion was about, however, you’ve warped it into a completely different problem space. > > Not really. The original posts posited that there were perfectly valid reasons to send deauth frames to "rogue" AP's because clients might connect to "spoofed" SSIDs. That's a bad solution to what at its heart is an authentication problem. Bring strong auth to the table, and there's no reason to worry about "spoofed" SSID's. Mike From rirving at antient.org Mon Oct 6 18:02:15 2014 From: rirving at antient.org (Richard Irving) Date: Mon, 06 Oct 2014 14:02:15 -0400 Subject: A few Baltimore tips for this week In-Reply-To: <20141006171133.GA6062@gsp.org> References: <20141006171133.GA6062@gsp.org> Message-ID: <5432D927.8010002@antient.org> Anyone coming or leaving via BWI airport : http://www.bwiairport.com/en/shops/shop-dine/store/obryckisab/ *Obrycki's *is an absolute /*must*/ for Authentic Maryland crab cakes, the ones they show on the food channel, and "my grandmother made". Get them *pan fried*, ignore all the other pretend methods of creating an Authentic Maryland Crab cake, they are not authentic. You may want to eat them with "Heinz" on the side, like a dip. Don't worry about asking for ketchup, no chef in Maryland will complain, it will probably be on the table, anyway. Next time you see Bobby Flay winning a throw down with _Maryland__ __Blue Crab,_ Crab Cakes, you can say you have had the real thing, and will understand /why/ he won. And heed our good friends advice here, and don't get too far off the beaten path.... You may become a "Bawlmer Merlund statistic, hon." On 10/06/2014 01:11 PM, Rich Kulawiec wrote: > Restaurants worth visiting: the Waterfront Kitchen (pricey, worth it, > harbor views), The Helmand (Afghan, delicious, charming hosts), > McCormick & Schmick's (seafood, harbor views), The Black Olive (Greek), > B&O Brasserie (great cocktails too), Sotto Sopra (Italian), > Da Mimmo's (Italian) > From dougb at dougbarton.us Mon Oct 6 18:39:41 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 06 Oct 2014 11:39:41 -0700 Subject: A few Baltimore tips for this week In-Reply-To: <20141006171133.GA6062@gsp.org> References: <20141006171133.GA6062@gsp.org> Message-ID: <5432E1ED.4010108@dougbarton.us> On 10/6/14 10:11 AM, Rich Kulawiec wrote: > Fort McHenry If you're a fan of history, or just an American, I can't recommend visiting Fort McHenry highly enough. When I was there (which admittedly was a long time ago) they did an excellent job of "setting the scene" for the battle that inspired Francis Scott Key to write "Defence of Fort M'Henry," nee "The Star-Spangled Banner." For me it was very inspirational, and if you have any doubts about whether or not that song should be our national anthem, visiting the star fort will dispel them. ... we now return you to our regularly scheduled cynical sniping ... Doug From clay at bloomcounty.org Mon Oct 6 18:53:40 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Mon, 6 Oct 2014 11:53:40 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> On Oct 6, 2014, at 8:41 AM, Owen DeLong wrote: > > Actually, in multiple situations, the FCC has stated that you are responsible > when deploying a new unlicensed transmitter to insure that it is deployed in > such a way that it will not cause harmful interference to existing operations. I recognize that you were making this statement in the context of colliding SSIDs, but to me this could be an interesting point in another way. Suppose from Marriott’s perspective that your personal wifi network is interfering with the throughput of their existing network. After all, if you fire up your personal AP, with a non-colliding SSID, and start downloading multi-GB files, that’s bound to impact[1] anything else using that channel. While there are at least a few non-overlapping channels on most wifi networks, if Marriott(’s third party network operators) had any sense they likely would have situated their APs and channels to provide the most range with the least amount of frequency overlap. Now here your personal AP on one of those channels consuming enough of its bandwidth to significantly degrade performance for anyone else, and they may not have access to (or usable signal strength or bandwidth on) another channel from their hotel room. During a big convention for example, the hotel network is probably at its busiest while the number of guests using personal APs is likely also at its peak. This may be a stickier case, as no one user is causing the issue but one could make the case that, in aggregate, they are very much interfering with existing operations. There are probably a couple of different angles to consider, but I’m thinking in terms of the “first come, first served” concept. At what point is the extra bandwidth consumed by your personal wifi network considered to be harmfully interfering with an existing network? FWIW I am not defending Marriott’s actions, nor even positing that this was the reason for them. I just want to gain understanding. -c [1] This is of course assuming you’re getting decent throughput from your 3G/4G provider’s network. But even though it’s almost certainly slower than wifi it’s probably generating enough packets in a collision-based medium to impact other flows. From hugo at slabnet.com Mon Oct 6 19:01:06 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 6 Oct 2014 12:01:06 -0700 Subject: Marriott wifi blocking In-Reply-To: <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> Message-ID: <20141006190106.GH1424@bamboo.slabnet.com> I live in a condo. I have a WLAN set up. More people move in and start setting up WLANs and the collective noise of those WLANs starts to impact the performance of my WLAN. Just because I was there first doesn't mean I have any right to start de-authing the newcomers. I don't see how Marriott has any additional rights to de-auth personal hotspots than I do to de-auth my neighbours. On Mon 2014-Oct-06 11:53:40 -0700, Clay Fiske wrote: > >On Oct 6, 2014, at 8:41 AM, Owen DeLong wrote: > >> >> Actually, in multiple situations, the FCC has stated that you are responsible >> when deploying a new unlicensed transmitter to insure that it is deployed in >> such a way that it will not cause harmful interference to existing operations. > >I recognize that you were making this statement in the context of colliding SSIDs, but to me this could be an interesting point in another way. > >Suppose from Marriott’s perspective that your personal wifi network is interfering with the throughput of their existing network. After all, if you fire up your personal AP, with a non-colliding SSID, and start downloading multi-GB files, that’s bound to impact[1] anything else using that channel. While there are at least a few non-overlapping channels on most wifi networks, if Marriott(’s third party network operators) had any sense they likely would have situated their APs and channels to provide the most range with the least amount of frequency overlap. Now here your personal AP on one of those channels consuming enough of its bandwidth to significantly degrade performance for anyone else, and they may not have access to (or usable signal strength or bandwidth on) another channel from their hotel room. > >During a big convention for example, the hotel network is probably at its busiest while the number of guests using personal APs is likely also at its peak. This may be a stickier case, as no one user is causing the issue but one could make the case that, in aggregate, they are very much interfering with existing operations. > >There are probably a couple of different angles to consider, but I’m thinking in terms of the “first come, first served” concept. At what point is the extra bandwidth consumed by your personal wifi network considered to be harmfully interfering with an existing network? > >FWIW I am not defending Marriott’s actions, nor even positing that this was the reason for them. I just want to gain understanding. > >-c > >[1] This is of course assuming you’re getting decent throughput from your 3G/4G provider’s network. But even though it’s almost certainly slower than wifi it’s probably generating enough packets in a collision-based medium to impact other flows. > -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bill at herrin.us Mon Oct 6 19:07:46 2014 From: bill at herrin.us (William Herrin) Date: Mon, 6 Oct 2014 15:07:46 -0400 Subject: Marriott wifi blocking In-Reply-To: <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> Message-ID: On Mon, Oct 6, 2014 at 2:53 PM, Clay Fiske wrote: > Suppose from Marriott’s perspective that your personal wifi > network is interfering with the throughput of their existing network. Then Marriott misunderstands the nature of *unlicensed* spectrum which anyone is allowed to use. There's a difference between interference incidental to one's lawful use and intentional, harmful interference. It isn't their spectrum. I have just as much a right to it as they do. If the microwave oven in the adjoining room makes 2.4ghz unusable I'm out of luck. If Marriott sends deauth packets (or any other unsolicited packets) under my SSID, they're hacking my computer and that's generally understood to be unlawful. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From clay at bloomcounty.org Mon Oct 6 19:56:44 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Mon, 6 Oct 2014 12:56:44 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> Message-ID: <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> On Oct 6, 2014, at 12:07 PM, William Herrin wrote: > On Mon, Oct 6, 2014 at 2:53 PM, Clay Fiske wrote: >> Suppose from Marriott’s perspective that your personal wifi >> network is interfering with the throughput of their existing network. > > Then Marriott misunderstands the nature of *unlicensed* spectrum which > anyone is allowed to use. There's a difference between interference > incidental to one's lawful use and intentional, harmful interference. > It isn't their spectrum. I have just as much a right to it as they do. > > If the microwave oven in the adjoining room makes 2.4ghz unusable I'm > out of luck. If Marriott sends deauth packets (or any other > unsolicited packets) under my SSID, they're hacking my computer and > that's generally understood to be unlawful. Again, to be clear, I’m not defending Marriott or their actions. I wouldn’t dispute your statements, but if the FCC set the tone as indicated by Owen then it sounds like it may not be that simple. Depending how it was actually worded by the FCC, I could see a corporation using it in court to defend their perceived “right" to protect their wifi network from being “disrupted” by other traffic. -c From dougb at dougbarton.us Mon Oct 6 20:16:28 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 06 Oct 2014 13:16:28 -0700 Subject: Marriott wifi blocking In-Reply-To: <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> Message-ID: <5432F89C.9050906@dougbarton.us> On 10/6/14 12:56 PM, Clay Fiske wrote: > Depending how it was actually worded by the FCC, I could see a corporation using it in court to defend their perceived “right" to protect their wifi network from being “disrupted” by other traffic. It's not clear that you understand how unlicensed spectrum works. The "right" you posit doesn't exist. The question of "Can we stomp on unauthorized users who are impersonating our ESSID(s)?" is a little more complex, as others have pointed out. But that's not what Marriot was doing. For my money the amount of uninformed speculation on this thread has exceeded even the normal levels for this list ... Doug From bill at herrin.us Mon Oct 6 20:16:08 2014 From: bill at herrin.us (William Herrin) Date: Mon, 6 Oct 2014 16:16:08 -0400 Subject: Marriott wifi blocking In-Reply-To: <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> Message-ID: On Mon, Oct 6, 2014 at 3:56 PM, Clay Fiske wrote: > On Oct 6, 2014, at 12:07 PM, William Herrin wrote: >> If the microwave oven in the adjoining room makes 2.4ghz unusable I'm >> out of luck. If Marriott sends deauth packets (or any other >> unsolicited packets) under my SSID, they're hacking my computer and >> that's generally understood to be unlawful. > > Again, to be clear, I’m not defending Marriott or their actions. > > I wouldn’t dispute your statements, but if the FCC set the >tone as indicated by Owen then it sounds like it may not > be that simple. Hi Clay, It isn't that simple. Marriott offended against multiple laws and regulations in multiple jurisdictions. The FCC's concern is use of the spectrum. This they addressed -- intentionally preventing others' use of the spectrum gets you spanked. Many states also have computer hacking laws where intentionally sending falsified data packets to a computer with the purpose of causing it to malfunction is either a tort or a crime. The FCC did not speak to that issue as it's out of their jurisdiction. We've discussed this on the list before: you don't get to counterattack a network you think is attacking you. It isn't lawful. Marriott should be grateful. They're lucky they only got slapped by the FCC. Had politicos been present they could have found themselves facing criminal charges. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From bhm at ufl.edu Mon Oct 6 20:35:54 2014 From: bhm at ufl.edu (Bruce H McIntosh) Date: Mon, 06 Oct 2014 16:35:54 -0400 Subject: A few Baltimore tips for this week In-Reply-To: <5432E1ED.4010108@dougbarton.us> References: <20141006171133.GA6062@gsp.org> <5432E1ED.4010108@dougbarton.us> Message-ID: <5432FD2A.9010503@ufl.edu> On 10/06/2014 02:39 PM, Doug Barton wrote: > On 10/6/14 10:11 AM, Rich Kulawiec wrote: >> Fort McHenry > > If you're a fan of history,... And if you can make it to the inner harbor area, on the west side of the Aquarium is USS Torsk, a WWII vintage US submarine, and on the east side of the Aquarium is the Coast Guard cutter USS Taney. Taney is the only remaining ship that participated in the battle of Pearl Harbor. She was in Honolulu harbor on 7 DEC 1941, and fired her antiaircraft guns at Japanese aircraft passing overhead on their way to the melee at Pearl. -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From jeffshultz at sctcweb.com Mon Oct 6 21:02:17 2014 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Mon, 06 Oct 2014 14:02:17 -0700 Subject: Other things in the Baltimore area Message-ID: <54330359.8070708@sctcweb.com> Two other places that might be worth a visit: (taking care to leave torches and pitchforks behind) The National Cryptologic Museum is located next to the National Security Agency HQ. It's really not that far away. https://www.nsa.gov/about/cryptologic_heritage/museum/ The B&O Train Museum is a must-see stop for anyone interested in railroads - http://www.borail.org/Collections.aspx I remember spending a fun afternoon several years ago (okay, so it's been over 15 years now...) just riding the water taxi around the harbor, getting off and wandering around Fells Point as well. -- Jeff Shultz From cb.list6 at gmail.com Mon Oct 6 21:27:48 2014 From: cb.list6 at gmail.com (Ca By) Date: Mon, 6 Oct 2014 14:27:48 -0700 Subject: socialsecurity.gov ipv6 routing loop Message-ID: in case anyone can help resolve traceroute6 www.socialsecurity.gov traceroute6: Warning: www.socialsecurity.gov has multiple addresses; using 2001:1930:c01::aaaa traceroute6 to www.socialsecurity.gov (2001:1930:c01::aaaa) from 2607:f2f8:a8e0::2, 64 hops max, 12 byte packets 1 2607:f2f8:a8e0::1 1.139 ms 0.798 ms 0.828 ms 2 ge-0-7-0-24.r04.lsanca03.us.bb.gin.ntt.net 1.159 ms 1.737 ms 1.098 ms 3 2001:428:201:8::1 0.718 ms 0.940 ms 0.976 ms 4 2001:428::205:171:3:171 74.411 ms 73.496 ms 74.080 ms 5 2001:428:a202::2:0:2 81.566 ms 81.726 ms 81.701 ms 6 www.socialsecurity.gov 76.344 ms 75.903 ms 75.638 ms 7 2001:1930:c01::2 76.694 ms 76.982 ms 76.726 ms 8 www.socialsecurity.gov 75.722 ms 75.774 ms 76.011 ms 9 2001:1930:c01::2 76.804 ms 77.080 ms 76.898 ms 10 www.socialsecurity.gov 75.967 ms 75.874 ms 75.842 ms 11 2001:1930:c01::2 76.901 ms 77.006 ms 76.907 ms 12 www.socialsecurity.gov 76.079 ms 76.390 ms 76.192 ms 13 2001:1930:c01::2 76.911 ms 77.246 ms 77.362 ms 14 www.socialsecurity.gov 76.032 ms 76.335 ms 76.327 ms 15 2001:1930:c01::2 77.239 ms 77.295 ms 77.903 ms 16 www.socialsecurity.gov 77.083 ms 76.307 ms 76.435 ms 17 2001:1930:c01::2 77.307 ms 77.427 ms 77.438 ms 18 www.socialsecurity.gov 76.468 ms 76.619 ms 78.225 ms 19 2001:1930:c01::2 77.242 ms 77.300 ms 77.371 ms 20 www.socialsecurity.gov 76.423 ms 76.444 ms 76.390 ms 21 2001:1930:c01::2 77.276 ms 77.277 ms 77.367 ms 22 www.socialsecurity.gov 76.610 ms 76.377 ms 76.669 ms 23 2001:1930:c01::2 77.318 ms 77.549 ms 77.201 ms 24 www.socialsecurity.gov 76.407 ms 76.250 ms 76.546 ms From clay at bloomcounty.org Mon Oct 6 22:03:06 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Mon, 6 Oct 2014 15:03:06 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> Message-ID: <2C0DB9A0-96DB-40E7-8C93-61E43FED39BC@bloomcounty.org> On Oct 6, 2014, at 1:16 PM, William Herrin wrote: > > Hi Clay, > > It isn't that simple. Marriott offended against multiple laws and > regulations in multiple jurisdictions. > > The FCC's concern is use of the spectrum. This they addressed -- > intentionally preventing others' use of the spectrum gets you spanked. Hi Bill, Right. So I think I was approaching it a different way, and I probably wasn’t clear enough about that. My question wasn’t meant to justify the response (deliberately booting people from non-Marriott SSIDs), it was about whether they had any legitimate right to claim that other wifi networks were impacting their own network’s performance, specifically based on the FCC’s position that a new transmitter should not disrupt existing operations. I was not in any way intending to say that their -response- was legitimate. Anyway, I think the departed horse has been suitably tenderized. Apologies for not being clearer, nothing to see here, etc. Thanks, -c From mpetach at netflight.com Mon Oct 6 22:25:20 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 6 Oct 2014 15:25:20 -0700 Subject: 2014.10.06 NANOG 62 morning notes posted Message-ID: Sorry, lunch was a bit short today, so didn't have time to post URL to morning notes over lunch as usual, sorry about that. ^_^;; Matt http://nanog.cluepon.net/index.php/NANOG62morn2 From mpetach at netflight.com Mon Oct 6 22:27:19 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 6 Oct 2014 15:27:19 -0700 Subject: 2014.10.06 NANOG 62 afternoon notes Message-ID: Bugger. Just realized I got the document names wrong. I'll just keep going with the wrong values, and pretend I didn't copy the dates from last time by mistake. ^_^; http://nanog.cluepon.net/index.php/NANOG62aft2 Thanks! :) Matt From mysidia at gmail.com Mon Oct 6 23:30:46 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 6 Oct 2014 18:30:46 -0500 Subject: Marriott wifi blocking In-Reply-To: <2C0DB9A0-96DB-40E7-8C93-61E43FED39BC@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> <2C0DB9A0-96DB-40E7-8C93-61E43FED39BC@bloomcounty.org> Message-ID: On Mon, Oct 6, 2014 at 5:03 PM, Clay Fiske wrote: >legitimate right to claim that other wifi networks were impacting their own >network’s performance, specifically based on the FCC’s position that a new > transmitter should not disrupt existing operations. I was not in any way >intending to say that their -response- was legitimate. Hi.... the FCC's position about a transmitter not disrupting existing operations applies to various licensed frequencies but not the low-powered unlicensed transmitters. Please don't imagine that Part 15 devices have any regulatory protection against interference from any other Part 15 devices being operated, no matter which device is "new", except for the prohibition against Malicious/Willful interference. Of course, it is within the FCC's power to regulate, there just isn't this regulation in Part 15. -- -JH From bill at herrin.us Tue Oct 7 02:04:43 2014 From: bill at herrin.us (William Herrin) Date: Mon, 6 Oct 2014 22:04:43 -0400 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> <166552F8-CAF0-497F-8F68-DB5046B548CB@bloomcounty.org> <2C0DB9A0-96DB-40E7-8C93-61E43FED39BC@bloomcounty.org> Message-ID: On Mon, Oct 6, 2014 at 7:30 PM, Jimmy Hess wrote: > On Mon, Oct 6, 2014 at 5:03 PM, Clay Fiske wrote: >>legitimate right to claim that other wifi networks were impacting their own >>network’s performance, specifically based on the FCC’s position that a new >> transmitter should not disrupt existing operations. I was not in any way >>intending to say that their -response- was legitimate. > > Please don't imagine that Part 15 devices have any regulatory > protection against interference from any other Part 15 devices being > operated, no matter which device is "new", except for the prohibition > against Malicious/Willful interference. Hi Clay, The answer to the question you asked is: No, Marriott lacked any legitimate right to claim that other wifi networks were impacting their own network’s performance. Any such impact was incidental to those other individuals'' lawful use of an unlicensed frequency. A more interesting question (to me anyway) is: does vendor gear which facilitates willful interference, as the "equipment provided by well-known, reputable manufacturers" apparently did, comply with Part 15? Or does the presence of such features make the gear non-compliant, ergo unlawful. Regards. Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From jay at west.net Tue Oct 7 03:20:33 2014 From: jay at west.net (Jay Hennigan) Date: Mon, 06 Oct 2014 20:20:33 -0700 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: <54335C01.7030302@west.net> On 10/6/14, 8:41 AM, Owen DeLong wrote: > Actually, in multiple situations, the FCC has stated that you are responsible > when deploying a new unlicensed transmitter to insure that it is deployed in > such a way that it will not cause harmful interference to existing operations. > > Using the same SSID of someone else who is already present would, IMHO, > meet the test of “causing harmful interference”. Really? From a radio perspective if it isn't on the same RF channel? I'm not so sure about that. It might cause interference to the revenue stream, it could be considered a trademark infringement especially if it leads to a fake "splash page" with the Marriott logo, and it could certainly be used for malicious MITM purposes, but it doesn't cause harmful interference to the existing user from the perspective of radio frequency use. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From owen at delong.com Tue Oct 7 11:52:29 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Oct 2014 04:52:29 -0700 Subject: Marriott wifi blocking In-Reply-To: <5432D219.5050701@mtcc.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> Message-ID: On Oct 6, 2014, at 10:32 AM, Michael Thomas wrote: > On 10/06/2014 10:12 AM, Owen DeLong wrote: >> On Oct 6, 2014, at 8:06 AM, Michael Thomas wrote: >> >>> On 10/06/2014 07:37 AM, Owen DeLong wrote: >>>> On Oct 4, 2014, at 11:23 PM, Michael Thomas wrote: >>>> >>>>> On 10/04/2014 11:13 PM, Owen DeLong wrote: >>>>>> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations. >>>>>> >>>>>> Further, you seem to assume a level of control over client behavior that is rare in my experience. >>>>>> >>>>>> Owen >>>>>> >>>>> I this particular case, I think that enterprise could go a very long way to driving a solution through >>>>> standards and deployment. They, after all, call the shots of who does and who doesn't get over >>>>> the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma. >>>> Not sure what you mean by corpro-drawbridge in this context. >>>> >>>> Some corporations exercise extreme control over their clients. They are the exception, not the rule. >>>> >>>> The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc. >>>> >>>> >>> It means that they can exercise control of what they allow on their corporate network, byod or not. Nobody >>> would allow a WEP-only wireless device on their network these days, so it's not hard to imagine that if a standard >>> for authenticating AP's became available and enterprises went to the effort to upgrade their AP kit, they could >>> reasonably say "use a client that supports this, or you must vpn in”. >> I think most environments already support this to some extent in terms of the APs participating in the controller framework and 802.1x authentication. >> >> However, that doesn’t cover the guy that brings a linksys in and plugs it into his wired port. >> >> I think the only solution for those is detection followed by blocking the wired port until resolution. > > If there's strong auth to the AP which enforces which SSID I connect to, who cares about somebody bringing their > own AP and fire up an SSID with the same name as $COPROSSID? Who said he’d use $CORPROSSID? He’ll probably use Linksys, leave it wide open, and, you know, your internal network just became accessible to any script-kiddie on a nearby mountain top with a coffee can. I’m going to guess that most IT managers and CSOs would be unhappy with that situation, but perhaps I am wrong. >> Most companies I have worked with that took the time to think this through simply made it an instant firing offense for anyone to plug in an unauthorized WAP to the corporate wired network, problem solved. > > That's orthogonal to somebody backhauling the AP's traffic to some other (possibly evil) network. And back hauling the AP’s traffic to some other (possibly evil) network is completely orthogonal to ANY of the threads in this discussion. >>> That's a much better outcome than quibbling about squatter's rights, blah blah blah. >> To the extent that such is a feasible solution, I think it was long since done. That’s got nothing to do with what this discussion was about, however, you’ve warped it into a completely different problem space. >> >> > > Not really. The original posts posited that there were perfectly valid reasons to send deauth frames to "rogue" AP's because > clients might connect to "spoofed" SSIDs. That's a bad solution to what at its heart is an authentication problem. Bring strong > auth to the table, and there's no reason to worry about "spoofed" SSID’s. That doesn’t mean that 802.1x doesn’t address the issue exactly as you described. People argue all kinds of things and there are lots of networks that haven’t deployed 802.1x and/or strong authentication (WPA2-Enterprise, et. al). Failure to deploy the tools doesn’t mean the tools and standards don’t exist. Owen From owen at delong.com Tue Oct 7 12:05:48 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Oct 2014 05:05:48 -0700 Subject: Marriott wifi blocking In-Reply-To: <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <07A070D3-C36A-48F2-A40D-7F57E28341BA@bloomcounty.org> Message-ID: <9A6EAA74-1B0B-4F9E-932B-F25010260BE4@delong.com> On Oct 6, 2014, at 11:53 AM, Clay Fiske wrote: > > On Oct 6, 2014, at 8:41 AM, Owen DeLong wrote: > >> >> Actually, in multiple situations, the FCC has stated that you are responsible >> when deploying a new unlicensed transmitter to insure that it is deployed in >> such a way that it will not cause harmful interference to existing operations. > > I recognize that you were making this statement in the context of colliding SSIDs, but to me this could be an interesting point in another way. > > Suppose from Marriott’s perspective that your personal wifi network is interfering with the throughput of their existing network. After all, if you fire up your personal AP, with a non-colliding SSID, and start downloading multi-GB files, that’s bound to impact[1] anything else using that channel. While there are at least a few non-overlapping channels on most wifi networks, if Marriott(’s third party network operators) had any sense they likely would have situated their APs and channels to provide the most range with the least amount of frequency overlap. Now here your personal AP on one of those channels consuming enough of its bandwidth to significantly degrade performance for anyone else, and they may not have access to (or usable signal strength or bandwidth on) another channel from their hotel room. The FCC has specifically stated that sharing of the spectrum bandwidth in this manner is not considered “harmful interference” in at least a few rulings. This is the “normal and expected result of deployment of multiple networks onto limited spectrum”. > During a big convention for example, the hotel network is probably at its busiest while the number of guests using personal APs is likely also at its peak. This may be a stickier case, as no one user is causing the issue but one could make the case that, in aggregate, they are very much interfering with existing operations. Yes, but not in a manner the FCC fits into the definition of “harmful interference” under 15.3 and/or 15.5. > There are probably a couple of different angles to consider, but I’m thinking in terms of the “first come, first served” concept. At what point is the extra bandwidth consumed by your personal wifi network considered to be harmfully interfering with an existing network? It isn’t (unless you run afoul of 47CFR333 and are consuming bandwidth for the sole purpose of denying it to others). > FWIW I am not defending Marriott’s actions, nor even positing that this was the reason for them. I just want to gain understanding. Yep. Understood. Hope the above helps. > -c > > [1] This is of course assuming you’re getting decent throughput from your 3G/4G provider’s network. But even though it’s almost certainly slower than wifi it’s probably generating enough packets in a collision-based medium to impact other flows. Actually, I usually get better 4G service on my LTE devices than I get from most hotel WiFi networks. It’s one of the reasons I wish Apple would let me choose the interface preference order rather than locking me to “if Wifi is on and can find an AP, then I won’t use LTE”. Owen From seth.mos at dds.nl Tue Oct 7 13:01:01 2014 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 07 Oct 2014 15:01:01 +0200 Subject: Netalyzr Android: call for volunteers In-Reply-To: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> References: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> Message-ID: <5433E40D.6070806@dds.nl> Srikanth Sundaresan schreef op 6-10-2014 0:43: > Hi all, > > Netalyzr is a free network measurement and debugging app developed > by the International Computer Science Institute, Berkeley. > Hi, Maybe it's just me, but my Xperia T (LT30p) does have IPv6 on Wifi and test-ipv6.com validates it. It runs Android 4.3. However, the Netalyzer apps has told me in 2 consecutive runs that it does not have IPv6 support. That does not appear intended. Kind regards, Seth From swmike at swm.pp.se Tue Oct 7 13:24:46 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Oct 2014 15:24:46 +0200 (CEST) Subject: Netalyzr Android: call for volunteers In-Reply-To: <5433E40D.6070806@dds.nl> References: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> <5433E40D.6070806@dds.nl> Message-ID: On Tue, 7 Oct 2014, Seth Mos wrote: > Maybe it's just me, but my Xperia T (LT30p) does have IPv6 on Wifi and > test-ipv6.com validates it. It runs Android 4.3. > > However, the Netalyzer apps has told me in 2 consecutive runs that it > does not have IPv6 support. > > That does not appear intended. My Nexus4 with Android 4.4.4 seems to run as intended, testing both IPv4 and IPv6 over Wifi. I wasn't aware that this was available for Android and applaud that the app exists as this means it's easier to do these tests in some places because of the Java requirement when running on PCs. My testing worked as expected, great job! -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Tue Oct 7 13:21:11 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Oct 2014 09:21:11 -0400 Subject: Marriott wifi blocking In-Reply-To: <54335C01.7030302@west.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <54335C01.7030302@west.net> Message-ID: <2C9CDA4C-BF0E-4FB8-A1ED-0C1A5453EC83@delong.com> > On Oct 6, 2014, at 11:20 PM, Jay Hennigan wrote: > >> On 10/6/14, 8:41 AM, Owen DeLong wrote: >> >> Actually, in multiple situations, the FCC has stated that you are responsible >> when deploying a new unlicensed transmitter to insure that it is deployed in >> such a way that it will not cause harmful interference to existing operations. >> >> Using the same SSID of someone else who is already present would, IMHO, >> meet the test of “causing harmful interference”. > > Really? From a radio perspective if it isn't on the same RF channel? In fact, yes. Since clients bind based on SSID and return to whatever channel the AP tells them to as a result, it's still an issue and still fits within the purview of RF regulation. Further, most of the channels somewhat overlap as it's a spread-spectrum technology, so the traditional concepts of "channel" don't actually completely apply (this is a good thing, actually). > I'm not so sure about that. It might cause interference to the revenue > stream, it could be considered a trademark infringement especially if it > leads to a fake "splash page" with the Marriott logo, and it could > certainly be used for malicious MITM purposes, but it doesn't cause > harmful interference to the existing user from the perspective of radio > frequency use. It does, actually, because the client may well rebind to the other AP thinking it's still part of the same ESS (since ESS are usually identified by sharing a common SSID). Owen From Luke.Parrish at Suddenlink.com Tue Oct 7 13:43:19 2014 From: Luke.Parrish at Suddenlink.com (Parrish, Luke) Date: Tue, 7 Oct 2014 13:43:19 +0000 Subject: Belkin Router issues this morning? Message-ID: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> Anyone out there seeing issues with Belkin routers connecting? I have also noticed that Belkins website has 80 percent packet loss and their support number is busy. Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455 ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. ________________________________ From nick at flhsi.com Tue Oct 7 13:56:32 2014 From: nick at flhsi.com (Nick Olsen) Date: Tue, 7 Oct 2014 09:56:32 -0400 Subject: Belkin Router issues this morning? In-Reply-To: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> Message-ID: <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> Seeing reports bounce around on the WISPA lists. Looks to be widespread. Reports on their twitter as well. I've had one customer with an issue related thus far. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Parrish, Luke" Sent: Tuesday, October 07, 2014 9:48 AM To: "nanog at nanog.org" Subject: Belkin Router issues this morning? Anyone out there seeing issues with Belkin routers connecting? I have also noticed that Belkins website has 80 percent packet loss and their support number is busy. Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455 ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. ________________________________ From JKrejci at usinternet.com Tue Oct 7 15:34:06 2014 From: JKrejci at usinternet.com (Justin Krejci) Date: Tue, 7 Oct 2014 15:34:06 +0000 Subject: Belkin Router issues this morning? In-Reply-To: <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com>, <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> Message-ID: <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> https://twitter.com/search?q=%23belkin Sounds like a bad firmware update most likely. Presumably the Belkin routers perform caching DNS for the LAN clients for if the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, etc) there are no longer any issues for those devices, as reported by several random people on the Internet. ________________________________________ From: Nick Olsen [nick at flhsi.com] Sent: Tuesday, October 07, 2014 8:56 AM To: Parrish, Luke; nanog at nanog.org Subject: re: Belkin Router issues this morning? Seeing reports bounce around on the WISPA lists. Looks to be widespread. Reports on their twitter as well. I've had one customer with an issue related thus far. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Parrish, Luke" Sent: Tuesday, October 07, 2014 9:48 AM To: "nanog at nanog.org" Subject: Belkin Router issues this morning? Anyone out there seeing issues with Belkin routers connecting? I have also noticed that Belkins website has 80 percent packet loss and their support number is busy. Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455 ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. ________________________________ From steve at blighty.com Tue Oct 7 16:05:33 2014 From: steve at blighty.com (Steve Atkins) Date: Tue, 7 Oct 2014 09:05:33 -0700 Subject: Belkin Router issues this morning? In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com>, <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: On Oct 7, 2014, at 8:34 AM, Justin Krejci wrote: > https://twitter.com/search?q=%23belkin > > Sounds like a bad firmware update most likely. > Presumably the Belkin routers perform caching DNS for the LAN clients for if the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, etc) there are no longer any issues for those devices, as reported by several random people on the Internet. Over on outages, someone mentioned that heartbeat.belkin.com was unreachable from some areas, and that was causing their routers to shut down. Cheers, Steve From wallacerl at verizon.net Tue Oct 7 16:50:26 2014 From: wallacerl at verizon.net (Ralph Wallace) Date: Tue, 07 Oct 2014 12:50:26 -0400 Subject: NANOG Digest, Vol 81, Issue 7 In-Reply-To: References: Message-ID: <076801cfe24e$cbf0dc00$63d29400$@net> Hi Group, We have a couple of circuits , internet facing with Level 3 and from our edge in San Diego, seeing some packet loss when trying a ping to 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? Packet sent with a source address of 63.214.184.3 !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! !!!!!!!!!.!!.!!!..!!!!!.!!!!.! Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms From edlewis.subscriber at cox.net Tue Oct 7 19:59:01 2014 From: edlewis.subscriber at cox.net (Edward Lewis) Date: Tue, 7 Oct 2014 15:59:01 -0400 Subject: Other things in the Baltimore area In-Reply-To: <54330359.8070708@sctcweb.com> References: <54330359.8070708@sctcweb.com> Message-ID: <5092161E-3B93-4C3C-8913-A2D52DF7B0E9@cox.net> On Oct 6, 2014, at 17:02, Jeff Shultz wrote: > The B&O Train Museum is a must-see stop for anyone interested in railroads - http://www.borail.org/Collections.aspx Following the trains & NANOG theme - one can visit the site of the Howard Street Tunnel fire: http://en.wikipedia.org/wiki/Howard_Street_Tunnel_fire or as NANOG saw it: https://www.nanog.org/mailinglist/mailarchives/old_archive/2001-07/msg00351.html loved this follow up: https://www.nanog.org/mailinglist/mailarchives/old_archive/2001-07/msg00370.html (I’m amazed how well the list is archived - this was over 13 years ago.) I was downtown at the time and they were telling every one that "the air was toxic, close your windows"…and me stuck in traffic in my convertible with a worn out (torn) roof. From SNaslund at medline.com Tue Oct 7 20:49:50 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 7 Oct 2014 20:49:50 +0000 Subject: Weird Issues within L3 In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40124FB7216@MUNPRDMBXA1.medline.com> Not a weird issue. It's called packet loss. You might want to try some traces to see where that loss is happening. Basic troubleshooting. Steve Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Khurram Khan Sent: Tuesday, October 07, 2014 1:36 PM To: nanog at nanog.org Subject: Weird Issues within L3 Hi Group, We have a couple of circuits , internet facing with Level 3 and from our edge in San Diego, seeing some packet loss when trying a ping to 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? Packet sent with a source address of 63.214.184.3 !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! !!!!!!!!!.!!.!!!..!!!!!.!!!!.! Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms From nick at flhsi.com Tue Oct 7 20:51:41 2014 From: nick at flhsi.com (Nick Olsen) Date: Tue, 7 Oct 2014 16:51:41 -0400 Subject: Weird Issues within L3 In-Reply-To: References: Message-ID: The 4.2.2.x machines are known to have some pretty heavy handed ICMP rate limits. I'd suggest trying to hit anything on level3 but those... Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Khurram Khan" Sent: Tuesday, October 07, 2014 4:48 PM To: "nanog at nanog.org" Subject: Weird Issues within L3 Hi Group, We have a couple of circuits , internet facing with Level 3 and from our edge in San Diego, seeing some packet loss when trying a ping to 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? Packet sent with a source address of 63.214.184.3 !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! !!!!!!!!!.!!.!!!..!!!!!.!!!!.! Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms From kkhan at brokenflea.net Tue Oct 7 21:13:49 2014 From: kkhan at brokenflea.net (Khurram Khan) Date: Tue, 7 Oct 2014 15:13:49 -0600 Subject: Weird Issues within L3 In-Reply-To: References: Message-ID: what's interesting is that out of my XO peering, I show no packet loss but out of L3, I do see packet loss. XO out of Denver: Sending 100, 100-byte ICMP Echos to 4.2.2.4, timeout is 2 seconds: Packet sent with a source address of 69.171.180.67 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 12/15/16 ms L3 out of San Diego: Packet sent with a source address of 63.214.184.3 !!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 98 percent (98/100), round-trip min/avg/max = 1/7/16 ms L3 out of Phoenix: Packet sent with a source address of 4.53.104.66 !!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!.!!!!!!!!!! Success rate is 97 percent (97/100), round-trip min/avg/max = 8/16/24 ms traceroute out of the L3 pop in San Diego Type escape sequence to abort. Tracing the route to 4.2.2.4 1 4.71.136.185 4 msec 4 msec 4 msec 2 4.2.2.4 12 msec 12 msec 16 msec On Tue, Oct 7, 2014 at 2:54 PM, Smith, Thomas wrote: > I'm dropping about 10 percent from the Sorrento Valley area. > > - - - - - - - - - > Thom Smith > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Khurram Khan > Sent: Tuesday, October 07, 2014 1:46 PM > To: nanog at nanog.org > Subject: Weird Issues within L3 > > Hi Group, > > We have a couple of circuits , internet facing with Level 3 and from our edge in San Diego, seeing some packet loss when trying a ping to 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? > > Packet sent with a source address of 63.214.184.3 !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! > !!!!!!!!!.!!.!!!..!!!!!.!!!!.! > Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms > This e-mail and any files transmitted with it may contain privileged and confidential information and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any dissemination or copying of this e-mail or any of its attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sending individual or entity by e-mail and permanently delete the original e-mail and attachment(s) from your computer system. Thank you for your cooperation. From blair.trosper at gmail.com Tue Oct 7 21:19:30 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 7 Oct 2014 16:19:30 -0500 Subject: Weird Issues within L3 In-Reply-To: References: Message-ID: Not to mention known bugs with how traffic is routed in large system like Google...because of any/multicast and all. (I hear it's a known bug internally.) I personally love the Level 3 public DNS servers, but they do carry some quirks with them, as all things in life do. On Tue, Oct 7, 2014 at 3:51 PM, Nick Olsen wrote: > The 4.2.2.x machines are known to have some pretty heavy handed ICMP rate > limits. > > I'd suggest trying to hit anything on level3 but those... > > Nick Olsen > Network Operations (855) FLSPEED x106 > > > ---------------------------------------- > From: "Khurram Khan" > Sent: Tuesday, October 07, 2014 4:48 PM > To: "nanog at nanog.org" > Subject: Weird Issues within L3 > Hi Group, > > We have a couple of circuits , internet facing with Level 3 and from > our edge in San Diego, seeing some packet loss when trying a ping to > 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? > > Packet sent with a source address of 63.214.184.3 > !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! > !!!!!!!!!.!!.!!!..!!!!!.!!!!.! > Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms > > > From Jason_Livingood at cable.comcast.com Tue Oct 7 21:54:09 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 7 Oct 2014 21:54:09 +0000 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com>, <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com>, Message-ID: <1B1E6AFB-CDE5-4182-AA3C-85A4BE1E0985@cable.comcast.com> Geesh. It was a tough day - lots of our customers with Belkin devices. Agree it has been fixable with customer changes but would have been better not to have to respond to this today (obviously). Regards, Jason Jason Livingood Comcast - Internet Services > On Oct 7, 2014, at 12:08, "Steve Atkins" wrote: > > >> On Oct 7, 2014, at 8:34 AM, Justin Krejci wrote: >> >> https://twitter.com/search?q=%23belkin >> >> Sounds like a bad firmware update most likely. >> Presumably the Belkin routers perform caching DNS for the LAN clients for if the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, etc) there are no longer any issues for those devices, as reported by several random people on the Internet. > > Over on outages, someone mentioned that heartbeat.belkin.com was unreachable from some areas, and that was causing their routers to shut down. > > Cheers, > Steve > > From jneiberger at gmail.com Tue Oct 7 22:27:16 2014 From: jneiberger at gmail.com (John Neiberger) Date: Tue, 7 Oct 2014 16:27:16 -0600 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: Sounds like it might have been a DNS issue of some sort. The end result was that the customer routers couldn't reach their heartbeat server, which made them think they weren't on the net. The routers would then be "helpful" and redirect all customer port 80 traffic to the router's configuration page to correct the "problem". It was a big mess that hopefully doesn't happen again. They've been making changes to their DNS this afternoon. Looks like they finally have it straightened out. John On Tue, Oct 7, 2014 at 10:05 AM, Steve Atkins wrote: > > On Oct 7, 2014, at 8:34 AM, Justin Krejci wrote: > > > https://twitter.com/search?q=%23belkin > > > > Sounds like a bad firmware update most likely. > > Presumably the Belkin routers perform caching DNS for the LAN clients > for if the LAN clients use alternate DNS servers (OpenDNS, Google, your > ISPs, etc) there are no longer any issues for those devices, as reported by > several random people on the Internet. > > Over on outages, someone mentioned that heartbeat.belkin.com was > unreachable from some areas, and that was causing their routers to shut > down. > > Cheers, > Steve > > From mike.lyon at gmail.com Tue Oct 7 22:32:24 2014 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 7 Oct 2014 15:32:24 -0700 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: And this, my friends, is why friends don't let friends buy Belkin... Apparently, you still can't fix stupid, no matter how hard you try. -Mike On Tuesday, October 7, 2014, John Neiberger wrote: > Sounds like it might have been a DNS issue of some sort. The end result was > that the customer routers couldn't reach their heartbeat server, which made > them think they weren't on the net. The routers would then be "helpful" and > redirect all customer port 80 traffic to the router's configuration page to > correct the "problem". > > It was a big mess that hopefully doesn't happen again. They've been making > changes to their DNS this afternoon. Looks like they finally have it > straightened out. > > John > > On Tue, Oct 7, 2014 at 10:05 AM, Steve Atkins > wrote: > > > > > On Oct 7, 2014, at 8:34 AM, Justin Krejci > wrote: > > > > > https://twitter.com/search?q=%23belkin > > > > > > Sounds like a bad firmware update most likely. > > > Presumably the Belkin routers perform caching DNS for the LAN clients > > for if the LAN clients use alternate DNS servers (OpenDNS, Google, your > > ISPs, etc) there are no longer any issues for those devices, as reported > by > > several random people on the Internet. > > > > Over on outages, someone mentioned that heartbeat.belkin.com was > > unreachable from some areas, and that was causing their routers to shut > > down. > > > > Cheers, > > Steve > > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From ktims at stargate.ca Tue Oct 7 22:32:56 2014 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 07 Oct 2014 15:32:56 -0700 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: <54346A18.2000002@stargate.ca> While we weren't really impacted by this issue, my understanding is that the Belkin devices ping 'heartbeat.belkin.com' periodically. If their pings fail, they do DNS redirection to the device's configuration interface and alert the user of the error. It appears that this server went down or had some sort of network issue, causing the redirect to kick in and users to be unable to access the Internet. Any solution that either a) avoids the router's DNS redirection or b) cause its pings to succeed would restore service. It looks like Belkin has now re-implemented this service on top of a DNS-cluster of AWS instances, so I think users are probably back online now, as the IPs in the initial reports were not AWS and are no longer in the DNS. Workarounds include: a) Add the IP(s) of the heartbeat server as loopbacks on a server/router within your (service provider) network that will respond to the echos for your customers b) Add the hostname 'heartbeat.belkin.com' to the router's host file as 127.0.0.1 c) Modify the DNS configuration of client machines or the Belkin DHCP server K On 10/07/2014 03:27 PM, John Neiberger wrote: > Sounds like it might have been a DNS issue of some sort. The end result was > that the customer routers couldn't reach their heartbeat server, which made > them think they weren't on the net. The routers would then be "helpful" and > redirect all customer port 80 traffic to the router's configuration page to > correct the "problem". > > It was a big mess that hopefully doesn't happen again. They've been making > changes to their DNS this afternoon. Looks like they finally have it > straightened out. > > John > > On Tue, Oct 7, 2014 at 10:05 AM, Steve Atkins wrote: > >> >> On Oct 7, 2014, at 8:34 AM, Justin Krejci wrote: >> >>> https://twitter.com/search?q=%23belkin >>> >>> Sounds like a bad firmware update most likely. >>> Presumably the Belkin routers perform caching DNS for the LAN clients >> for if the LAN clients use alternate DNS servers (OpenDNS, Google, your >> ISPs, etc) there are no longer any issues for those devices, as reported by >> several random people on the Internet. >> >> Over on outages, someone mentioned that heartbeat.belkin.com was >> unreachable from some areas, and that was causing their routers to shut >> down. >> >> Cheers, >> Steve >> >> From oz at columbus.rr.com Tue Oct 7 22:23:11 2014 From: oz at columbus.rr.com (Steven Parsons) Date: Tue, 07 Oct 2014 18:23:11 -0400 Subject: Belkin Router issues this morning? In-Reply-To: <1B1E6AFB-CDE5-4182-AA3C-85A4BE1E0985@cable.comcast.com> Message-ID: Looks like belkin¹s fix was to add different records. DNS response this morning. heartbeat.belkin.com. 4h14m31s IN A 67.20.176.130 DNS response this evening. dig heartbeat.belkin.com +short 54.163.115.57 23.20.47.97 54.227.172.225 54.161.217.33 54.163.87.225 54.87.220.73 54.163.74.132 54.83.179.150 54.196.247.165 54.163.72.1 54.87.180.46 54.242.182.61 174.129.92.187 On 10/7/14, 5:54 PM, "Livingood, Jason" wrote: > Geesh. It was a tough day - lots of our customers with Belkin devices. Agree > it has been fixable with customer changes but would have been better not to > have to respond to this today (obviously). > > Regards, > Jason > > Jason Livingood > Comcast - Internet Services > >> On Oct 7, 2014, at 12:08, "Steve Atkins" wrote: >> >> >>> On Oct 7, 2014, at 8:34 AM, Justin Krejci wrote: >>> >>> https://twitter.com/search?q=%23belkin >>> >>> Sounds like a bad firmware update most likely. >>> Presumably the Belkin routers perform caching DNS for the LAN clients for >>> if the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, >>> etc) there are no longer any issues for those devices, as reported by >>> several random people on the Internet. >> >> Over on outages, someone mentioned that heartbeat.belkin.com was unreachable >> from some areas, and that was causing their routers to shut down. >> >> Cheers, >> Steve >> >> > From Valdis.Kletnieks at vt.edu Tue Oct 7 23:08:57 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2014 19:08:57 -0400 Subject: Belkin Router issues this morning? In-Reply-To: Your message of "Tue, 07 Oct 2014 16:27:16 -0600." References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: <28139.1412723337@turing-police.cc.vt.edu> On Tue, 07 Oct 2014 16:27:16 -0600, John Neiberger said: > Sounds like it might have been a DNS issue of some sort. The end result was > that the customer routers couldn't reach their heartbeat server, which made > them think they weren't on the net. Seems like a dubious idea to equate "can't reach heartbeat server" with "not on the net at all". At the very least, I'd add a second clause "I have no reachable default route, and I must scream". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From list at satchell.net Tue Oct 7 23:27:09 2014 From: list at satchell.net (Stephen Satchell) Date: Tue, 07 Oct 2014 16:27:09 -0700 Subject: Weird Issues within L3 In-Reply-To: References: Message-ID: <543476CD.5010907@satchell.net> On 10/07/2014 11:36 AM, Khurram Khan wrote: > Hi Group, > > We have a couple of circuits , internet facing with Level 3 and from > our edge in San Diego, seeing some packet loss when trying a ping to > 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? > > Packet sent with a source address of 63.214.184.3 > !.!!!.!!!!!!!!!!!!!...!!!..!!!!!!.!!.!!!!!!.!..!!.!!.!!!!!!!!!!!!!!!!! > !!!!!!!!!.!!.!!!..!!!!!.!!!!.! > Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms > I'm not with level3, but the pattern looks exactly like what happens when a destination node has rather severe rate-limiting in place, and multiple people are sending ICMP. Try spacing your ping packets. On Linux, the command switch is "ping -i 3" to send packets every three seconds; for MTR it's "mtr -i 3" -- If you are using something else, there should be an "interval" parameter that you can set to minimize rate-limiting effects. Have you tried sending real traffic to 4.2.2.4, and looking at the packet traffic? From larrysheldon at cox.net Wed Oct 8 00:28:24 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 07 Oct 2014 19:28:24 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0BxG1p0131cZc5601BxJMf> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <0BxG1p0131cZc5601BxJMf> Message-ID: <54348528.9060708@cox.net> I have a question for the company assembled: Suppose that instead of [name of company] being offended by people using their own data paths instead to the pricey choice offered, [name of company] took the position that people should use the voice telephone service they offered and block cell phone service on (and near) their property. What would change in the several arguments that have been presented? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From ktims at stargate.ca Wed Oct 8 00:43:27 2014 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 07 Oct 2014 17:43:27 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54348528.9060708@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <0BxG1p0131cZc5601BxJMf> <54348528.9060708@cox.net> Message-ID: <543488AF.40806@stargate.ca> I don't think it changes much. Passive methods (ie. Faraday cage) would likely be fine, as would layer 8 through 10 methods. Actively interfering with the RF would probably garner them an even bigger smackdown than they got here, as these are licensed bands where the mobile carrier is the primary or secondary user. [name of company] has no right to even use the frequencies in question. Seems pretty consistent to me. K On 10/07/2014 05:28 PM, Larry Sheldon wrote: > I have a question for the company assembled: > > Suppose that instead of [name of company] being offended by people using > their own data paths instead to the pricey choice offered, [name of > company] took the position that people should use the voice telephone > service they offered and block cell phone service on (and near) their > property. > > What would change in the several arguments that have been presented? > From larrysheldon at cox.net Wed Oct 8 00:56:27 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 07 Oct 2014 19:56:27 -0500 Subject: Belkin Router issues this morning? In-Reply-To: <0NZE1p01e1cZc5601NZG0j> References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> <0NZE1p01e1cZc5601NZG0j> Message-ID: <54348BBB.3000403@cox.net> On 10/7/2014 17:32, Mike Lyon wrote: > And this, my friends, is why friends don't let friends buy Belkin... Amen. Side question? What happens is somebody is unwise to use Belkin routers on an internal, not-connected-to-the-Interatubes network (Like, for example, the network I tried to get ex-employer to install to serve the un-patched Windows 98 heart monitors and stuff that were favored targets of the crackers. I am having trouble understanding why a router would need a heartbeat from some foreign location. Or even what it would do with one. > Apparently, you still can't fix stupid, no matter how hard you try. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From mysidia at gmail.com Wed Oct 8 01:10:44 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 7 Oct 2014 20:10:44 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <543488AF.40806@stargate.ca> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> Message-ID: On Tue, Oct 7, 2014 at 7:43 PM, Keenan Tims wrote: > I don't think it changes much. Passive methods (ie. Faraday cage) would > likely be fine, as would layer 8 through 10 methods. Well... actually... passive methods are probably fine, as long as they are not breaking reception to nearby properties, BUT it might result in some proceedings or investigations regarding anticompetitive behaviors --- also, if there are other businesses nearby, it could lead to some objections when you go seeking permits to build this giant faraday cage. The local authorities might eventually require some modifications. :) > Actively interfering with the RF would probably garner them an even > bigger smackdown than they got here, as these are licensed bands where It's even worse.... these frequencies are licensed, and willfully transmitting into the frequencies with enough power to block cell calls from an unauthorized station has severe penalties, even if it never interferes with a single phone or the licensee's use of the restricted frequencies. If it DOES interfere, then you have two potential violations (Unauthorized emission PLUS Interference) and there are likely more stations they would be interfering with than WiFi APs, so there are more violations and more complaints likely to be generated. And these violations are more severe, since they can interfere with emergency communications (E911); I think it's fair to say penalties would likely be larger. The only way to legally block cell phone RF would likely be on behalf of the licensee ---- In other words, possibly, persuade the cell phone companies to allow this, then create an approved "special" local cell tower all their phones in the same building will by default connect to in preference to any other, which will also not receive any calls or messages or allow any to be sent. -- -JH From Valdis.Kletnieks at vt.edu Wed Oct 8 01:36:26 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Oct 2014 21:36:26 -0400 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: Your message of "Tue, 07 Oct 2014 20:10:44 -0500." References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> Message-ID: <35458.1412732186@turing-police.cc.vt.edu> On Tue, 07 Oct 2014 20:10:44 -0500, Jimmy Hess said: > The only way to legally block cell phone RF would likely be on behalf > of the licensee ---- In other words, possibly, persuade the cell > phone companies to allow this, then create an approved "special" > local cell tower all their phones in the same building will by > default connect to in preference to any other, which will also not > receive any calls or messages or allow any to be sent. I wonder how many customers the cell phone company will attract by doing that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From r.engehausen at gmail.com Wed Oct 8 01:59:22 2014 From: r.engehausen at gmail.com (Roy) Date: Tue, 07 Oct 2014 18:59:22 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <35458.1412732186@turing-police.cc.vt.edu> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> Message-ID: <54349A7A.5060702@gmail.com> The SF Bay Area Rapid Transits System) turned off cellphones in 2011. http://www.sfgate.com/news/article/BART-admits-halting-cell-service-to-stop-protests-2335114.php and the FCC emphasis that future actions "recognizes that any interruption of cell phone service poses serious risks to public safety" http://www.sfgate.com/bayarea/article/BART-cell-phone-shutdown-rules-adopted-2344326.php On 10/7/2014 6:36 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 07 Oct 2014 20:10:44 -0500, Jimmy Hess said: > >> The only way to legally block cell phone RF would likely be on behalf >> of the licensee ---- In other words, possibly, persuade the cell >> phone companies to allow this, then create an approved "special" >> local cell tower all their phones in the same building will by >> default connect to in preference to any other, which will also not >> receive any calls or messages or allow any to be sent. > I wonder how many customers the cell phone company will attract by doing that. > From morrowc.lists at gmail.com Wed Oct 8 02:14:26 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Oct 2014 22:14:26 -0400 Subject: Belkin Router issues this morning? In-Reply-To: <54348BBB.3000403@cox.net> References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> <54348BBB.3000403@cox.net> Message-ID: On Tue, Oct 7, 2014 at 8:56 PM, Larry Sheldon wrote: > I am having trouble understanding why a router would need a heartbeat from > some foreign location. Or even what it would do with one. One, not crazy, line of thinking is that: "Instead of being cryptic and difficult to understand, help the customer to know that: "your dsl is boarked" and that offloading that call set from the ISP for something that might be simple to fix at the CPE might make the ISP folk happy. Of course that decision process came with the decision to run a reliable and always-on service...oops. From larrysheldon at cox.net Wed Oct 8 02:34:30 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 07 Oct 2014 21:34:30 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0S0G1p0071cZc5601S0H2i> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> Message-ID: <5434A2B6.7000007@cox.net> On 10/7/2014 20:59, Roy wrote: > > The SF Bay Area Rapid Transits System) turned off cellphones in 2011. > > http://www.sfgate.com/news/article/BART-admits-halting-cell-service-to-stop-protests-2335114.php > > > and the FCC emphasis that future actions "recognizes that any > interruption of cell phone service poses serious risks to public safety" > > http://www.sfgate.com/bayarea/article/BART-cell-phone-shutdown-rules-adopted-2344326.php I see that as a fundamentally very different mater. If I understand, they turned off repeaters ("towers") that they owned and provided, in tunnels and other structures they owned--equipment that they were under no obligation whatever to provide. A reaction to "bright" marketing ideas that had not been thought-through. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From mpalmer at hezmatt.org Wed Oct 8 03:27:38 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 8 Oct 2014 14:27:38 +1100 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <35458.1412732186@turing-police.cc.vt.edu> References: <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> Message-ID: <20141008032738.GO5312@hezmatt.org> On Tue, Oct 07, 2014 at 09:36:26PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Tue, 07 Oct 2014 20:10:44 -0500, Jimmy Hess said: > > > The only way to legally block cell phone RF would likely be on behalf > > of the licensee ---- In other words, possibly, persuade the cell > > phone companies to allow this, then create an approved "special" > > local cell tower all their phones in the same building will by > > default connect to in preference to any other, which will also not > > receive any calls or messages or allow any to be sent. > > I wonder how many customers the cell phone company will attract by doing that. Getting paid by third parties to abuse your customers seems to be working well for certain other industries. - Matt -- "You keep using that word. I do not think it means what you think it means." -- Inigo, The Princess Bride From r.engehausen at gmail.com Wed Oct 8 03:28:32 2014 From: r.engehausen at gmail.com (Roy) Date: Tue, 07 Oct 2014 20:28:32 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <5434A2B6.7000007@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> Message-ID: <5434AF60.1020908@gmail.com> On 10/7/2014 7:34 PM, Larry Sheldon wrote: > On 10/7/2014 20:59, Roy wrote: >> >> The SF Bay Area Rapid Transits System) turned off cellphones in 2011. >> >> http://www.sfgate.com/news/article/BART-admits-halting-cell-service-to-stop-protests-2335114.php >> >> >> >> and the FCC emphasis that future actions "recognizes that any >> interruption of cell phone service poses serious risks to public safety" >> >> http://www.sfgate.com/bayarea/article/BART-cell-phone-shutdown-rules-adopted-2344326.php >> > > I see that as a fundamentally very different mater. > > If I understand, they turned off repeaters ("towers") that they owned > and provided, in tunnels and other structures they owned--equipment > that they were under no obligation whatever to provide. > > A reaction to "bright" marketing ideas that had not been thought-through. > BART's equipment was licensed by the FCC with a main reason being 911 access. From larrysheldon at cox.net Wed Oct 8 04:10:15 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 07 Oct 2014 23:10:15 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0TYp1p00X1cZc5601TYr2E> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> <0TYp1p00X1cZc5601TYr2E> Message-ID: <5434B927.8080400@cox.net> On 10/7/2014 22:28, Roy wrote: > On 10/7/2014 7:34 PM, Larry Sheldon wrote: >> On 10/7/2014 20:59, Roy wrote: >>> >>> The SF Bay Area Rapid Transits System) turned off cellphones in 2011. >>> >>> http://www.sfgate.com/news/article/BART-admits-halting-cell-service-to-stop-protests-2335114.php >>> >>> >>> >>> and the FCC emphasis that future actions "recognizes that any >>> interruption of cell phone service poses serious risks to public safety" >>> >>> http://www.sfgate.com/bayarea/article/BART-cell-phone-shutdown-rules-adopted-2344326.php >>> >> >> I see that as a fundamentally very different mater. >> >> If I understand, they turned off repeaters ("towers") that they owned >> and provided, in tunnels and other structures they owned--equipment >> that they were under no obligation whatever to provide. >> >> A reaction to "bright" marketing ideas that had not been thought-through. >> > > BART's equipment was licensed by the FCC with a main reason being 911 > access. OK--not a Marketing idea, maybe. But still, all the options are in BART's hands--they have emergency phones and people everywhere. The cell service is not a requirement placed upon them, I am pretty sure. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From Valdis.Kletnieks at vt.edu Wed Oct 8 04:44:23 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Oct 2014 00:44:23 -0400 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: Your message of "Tue, 07 Oct 2014 23:10:15 -0500." <5434B927.8080400@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> <0TYp1p00X1cZc5601TYr2E> <5434B927.8080400@cox.net> Message-ID: <43605.1412743463@turing-police.cc.vt.edu> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: > The cell service is not a requirement placed upon them, I am pretty sure. However, once having chosen to provide it, and thus create an expectation that cellular E911 is available, they're obligated to carry through on that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From larrysheldon at cox.net Wed Oct 8 05:35:21 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 08 Oct 2014 00:35:21 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0VPi1p00G0No1gJ01VPksi> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> <0TYp1p00X1cZc5601TYr2E> <5434B927.8080400@cox.net> <0VPi1p00G0No1gJ01VPksi> Message-ID: <5434CD19.8050704@cox.net> On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: > On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >> The cell service is not a requirement placed upon them, I am pretty sure. > > However, once having chosen to provide it, and thus create an expectation > that cellular E911 is available, they're obligated to carry through on > that. > Obligated by what law, regulation, rule or contract? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Wed Oct 8 05:42:57 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 08 Oct 2014 00:42:57 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0Vc61p00p1cZc5601Vc8Me> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> <0TYp1p00X1cZc5601TYr2E> <5434B927.8080400@cox.net> <0VPi1p00G0No1gJ01VPksi> <0Vc61p00p1cZc5601Vc8Me> Message-ID: <5434CEE1.5010604@cox.net> On 10/8/2014 00:35, Larry Sheldon wrote: > On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >>> The cell service is not a requirement placed upon them, I am pretty >>> sure. >> >> However, once having chosen to provide it, and thus create an expectation >> that cellular E911 is available, they're obligated to carry through on >> that. >> > Obligated by what law, regulation, rule or contract? > I lived in the area and worked in San Francisco when BART was built, and while I never rode BART regularly, I have no recall of cell service on BART or MUNI being a safety issue or advertised as such. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From dan at drakontas.org Wed Oct 8 00:38:55 2014 From: dan at drakontas.org (Daniel C. Eckert) Date: Tue, 7 Oct 2014 17:38:55 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54348528.9060708@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> Message-ID: Cell phone service relies on specially licensed wireless spectrum whereas WiFi relies on specifically unlicensed spectrum. The rules/laws/expectations are fundamentally different for the two cases you outlined. Dan On Oct 7, 2014 5:29 PM, "Larry Sheldon" wrote: > I have a question for the company assembled: > > Suppose that instead of [name of company] being offended by people using > their own data paths instead to the pricey choice offered, [name of > company] took the position that people should use the voice telephone > service they offered and block cell phone service on (and near) their > property. > > What would change in the several arguments that have been presented? > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes > From m.waehlisch at fu-berlin.de Wed Oct 8 07:36:02 2014 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Wed, 8 Oct 2014 09:36:02 +0200 Subject: Survey about RPKI/DNSSEC In-Reply-To: References: Message-ID: Hi folks, we already received 140 replies. Many thanks! We hope to gather some more responses. If you didn't participate in the survey so far, please help us to better understand the deployment of RPKI and DNSSEC: http://eSurv.org?u=rpkidnssec The survey is anonymous and should not take more than 5 minutes to commplete. Thanks matthias On Fri, 19 Sep 2014, Matthias Waehlisch wrote: > Hi NANOG, > > we, a group of researchers, try to better understand the deployment of > RPKI and DNSSEC. It's not always easy to find technical reasons for what > we observe. To get more insights why you deploy or don't deploy RPKI or > DNSSEC, we would like to ask you to participate in the following brief > survey: > > http://eSurv.org?u=rpkidnssec > > We really appreciate your time. It should not take more than 5 minutes > to complete the survey. > > The survey is anonymous. The results are only used to improve research > on inter-networking. If there is interest, we will post the results to > the list. > > Fell free to contact me offlist in case of further questions or > comments. > > > Many thanks! > > matthias > (on behalf of the team) > > > [This email has also been sent to RIPE and SIDR folks.] > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From r.engehausen at gmail.com Wed Oct 8 12:42:15 2014 From: r.engehausen at gmail.com (Roy) Date: Wed, 08 Oct 2014 05:42:15 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <5434CD19.8050704@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <0S0G1p0071cZc5601S0H2i> <5434A2B6.7000007@cox.net> <0TYp1p00X1cZc5601TYr2E> <5434B927.8080400@cox.net> <0VPi1p00G0No1gJ01VPksi> <5434CD19.8050704@cox.net> Message-ID: <54353127.4060406@gmail.com> On 10/7/2014 10:35 PM, Larry Sheldon wrote: > On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >>> The cell service is not a requirement placed upon them, I am pretty >>> sure. >> >> However, once having chosen to provide it, and thus create an >> expectation >> that cellular E911 is available, they're obligated to carry through on >> that. >> > Obligated by what law, regulation, rule or contract? > Obligated by the FCC license From bill at herrin.us Wed Oct 8 13:47:31 2014 From: bill at herrin.us (William Herrin) Date: Wed, 8 Oct 2014 09:47:31 -0400 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54353127.4060406@gmail.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> Message-ID: On Wed, Oct 8, 2014 at 8:42 AM, Roy wrote: > On 10/7/2014 10:35 PM, Larry Sheldon wrote: >> On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: >>> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >>>> The cell service is not a requirement placed upon them, I am pretty >>>> sure. >>> >>> However, once having chosen to provide it, and thus create an expectation >>> that cellular E911 is available, they're obligated to carry through on >>> that. >>> >> Obligated by what law, regulation, rule or contract? > > Obligated by the FCC license Hi Larry, Roy: BART would not have had an FCC license. They'd have had contracts with the various phone companies to co-locate equipment and provide wired backhaul out of the tunnels. The only thing they'd be guilty of is breach of contract, and that only if the cell phone companies decided their behavior was inconsistent with the SLA.. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From jeremyparr at gmail.com Wed Oct 8 13:48:48 2014 From: jeremyparr at gmail.com (Jeremy Parr) Date: Wed, 8 Oct 2014 09:48:48 -0400 Subject: Megapath contact Message-ID: Could someone from Megapath contact me offlist? I'm fighting with some very strange routing for a customer. From jlewis at lewis.org Wed Oct 8 13:53:57 2014 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 8 Oct 2014 09:53:57 -0400 (EDT) Subject: PLDT on the list? Message-ID: This may be a long shot, but if there's anyone on-list from PLDT who can help out with PLDT I-Gate customer prefix filtering updates, I'd appreciate some help with an issue that's been dragging on for weeks. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jtk at cymru.com Wed Oct 8 13:59:00 2014 From: jtk at cymru.com (John Kristoff) Date: Wed, 8 Oct 2014 08:59:00 -0500 Subject: Unwanted Traffic Removal Service (UTRS) Message-ID: <20141008085900.3b6f2a24@localhost> Friends and colleagues, Yesterday I briefly discussed a new project we've recently launched and for which invited participation from the NANOG 62 attendees. This is a not so subtle wider request for consideration. UTRS is essentially a community RTBH that people have suggested to us would be a good service to provide, so we're giving it a go. Yesterday's lightning talk page has the slide deck I presented: I've also put some additional technical detail here: If you have an assigned ASN and this sounds like something you or your network would like to take advantage of, drop me a line, I'd sure like to hear about it. If you think this is a terrible idea and want to express all that is wrong with it, tell me that too, I can take it. Even if you're unsure if you would ultimately deploy it in production, but are interested in testing it, do contact me. We won't expend energy on this project and will drop it if we there isn't sufficient interest from the community, but enough trial users would be encouraging. Kindly, John From Lee at asgard.org Wed Oct 8 14:18:27 2014 From: Lee at asgard.org (Lee Howard) Date: Wed, 08 Oct 2014 10:18:27 -0400 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> <54348BBB.3000403@cox.net> Message-ID: On 10/7/14 10:14 PM, "Christopher Morrow" wrote: >On Tue, Oct 7, 2014 at 8:56 PM, Larry Sheldon >wrote: >> I am having trouble understanding why a router would need a heartbeat >>from >> some foreign location. Or even what it would do with one. > >One, not crazy, line of thinking is that: "Instead of being cryptic >and difficult to understand, help the customer to know that: "your dsl >is boarked" and that offloading that call set from the ISP for >something that might be simple to fix at the CPE might make the ISP >folk happy. That would be not-crazy if there were congruence with "DSL borked" and "host unreachable." > >Of course that decision process came with the decision to run a >reliable and always-on service...oops. Clever! Lee From morrowc.lists at gmail.com Wed Oct 8 14:40:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Oct 2014 10:40:15 -0400 Subject: Belkin Router issues this morning? In-Reply-To: References: <10AB04B9CE55DF4AA248C0388F4ED464641BCCC2@SDLDALPWEMB07.suddenlink.cequel3.com> <67f8a1613a7947ceaddbc9205f4bb0e7@flhsi.com> <3E9C67DA261AC349B60FF3609F5E211D6A0CD5BA@USI-2K10EX01-MT.usicorp.usinternet.com> <54348BBB.3000403@cox.net> Message-ID: On Wed, Oct 8, 2014 at 10:18 AM, Lee Howard wrote: > > > On 10/7/14 10:14 PM, "Christopher Morrow" wrote: > >>On Tue, Oct 7, 2014 at 8:56 PM, Larry Sheldon >>wrote: >>> I am having trouble understanding why a router would need a heartbeat >>>from >>> some foreign location. Or even what it would do with one. >> >>One, not crazy, line of thinking is that: "Instead of being cryptic >>and difficult to understand, help the customer to know that: "your dsl >>is boarked" and that offloading that call set from the ISP for >>something that might be simple to fix at the CPE might make the ISP >>folk happy. > > That would be not-crazy if there were congruence with "DSL borked" and > "host unreachable." but see point 2 ... they were supposed to run a reliable always-on service.. oh, wait ,that's what you meant :( (this plan didn't get to step3 - profit!) >>Of course that decision process came with the decision to run a >>reliable and always-on service...oops. > > Clever! > > > Lee > > From job at instituut.net Wed Oct 8 14:42:38 2014 From: job at instituut.net (Job Snijders) Date: Wed, 8 Oct 2014 16:42:38 +0200 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008085900.3b6f2a24@localhost> References: <20141008085900.3b6f2a24@localhost> Message-ID: <20141008144238.GE10316@Vurt.local> Dear John, On Wed, Oct 08, 2014 at 08:59:00AM -0500, John Kristoff wrote: > UTRS is essentially a community RTBH that people have suggested to us > would be a good service to provide, so we're giving it a go. FYI, there are various projects which are similar to this concept: http://www.de-cix.net/products-services/de-cix-frankfurt/blackholing/ https://ripe68.ripe.net/presentations/369-bgp_bh_ripe.pdf https://wiki.rtbh.me/ > If you think this is a terrible idea and want to express all that is > wrong with it, tell me that too, I can take it. Just like chicory, personally I don't like it. Yes, Cymru has build a reputation as clearing house for redistribution of security related information. But... (aside from any local safety net filter), it's quite a leap to allow a single entity to inject blackholes for any prefix. There are various flavors at the moment in terms of validation (please correct me if I am wrong): The Polish blackholing project only allows blackholes which fall within the set of prefixes which an ASN originates, the DE-CIX BS service accepts anything that is a subset of your AS-SET. Both approaches have their downsides: you can make any AS or AS-SET a member of your AS-SET and thereby gain a degree of control on the RTBH server, and for $500/year you can register any route-object you want in RADB. RIPE is the only RIR which has the IRR service as a truely integral part of the database, allowing advanced automatable authentication schemes for purposes such as these. However, they only administrate for a subset of the Internet, making this direction inpractical for a universal solution. Might I suggest an alternative approach, without central validation or need for a clearing house: IXPs could offer BGP or API triggered ACLs which are inserted into the peering fabric and only affect the participant's peering port(s). This way, any blackholing (either correctly applied or malicious) only affects the initator of that blackhole and nobody else. Advantages are that aclserver does not require peers to cooperate with each other and no validation is required. Kind regards, Job From paigeadele at gmail.com Wed Oct 8 14:43:35 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Wed, 08 Oct 2014 17:43:35 +0300 Subject: netfilter/iptables synproxy; need help deciding Message-ID: <54354D97.5010706@gmail.com> Hi, I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of things to pick at but please try to focus on the subject of synproxy for the purpose of this e-mail.) based on the following table I want to say its not working because it seems to never change: http://pastie.org/private/xwct5opbb0aajcko2tnpw more info on /proc/stat/synproxy: http://www.spinics.net/lists/netdev/msg264350.html My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY I really would like to come to some closure on this subject. Whether it needs to be done right or not done at all, I'm tired of it looming over me. I really want to believe I should do the very best to have all mitigation techniques already in place, but I'm having a hard time understanding why this is next to impossible to figure out if it's so important. #netfilter on freenode is next to no help, the mailing list seems to be unavailable.... the things people are saying about how I should "just switch" back to using pf seem like a drastic solution when people in #netfilter are so content (yet many of them have never heard of synproxy before.) Any thoughts on this are appreciated, -Paige From paigeadele at gmail.com Wed Oct 8 14:51:06 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Wed, 8 Oct 2014 17:51:06 +0300 Subject: netfilter/iptables synproxy; need help deciding Message-ID: Hi, I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of things to pick at but please try to focus on the subject of synproxy for the purpose of this e-mail.) based on the following table I want to say its not working because it seems to never change: http://pastie.org/private/xwct5opbb0aajcko2tnpw more info on /proc/stat/synproxy:http://www.spinics.net/lists/netdev/msg264350.html My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY I really would like to come to some closure on this subject. Whether it needs to be done right or not done at all, I'm tired of it looming over me. I really want to believe I should do the very best to have all mitigation techniques already in place, but I'm having a hard time understanding why this is next to impossible to figure out if it's so important. #netfilter on freenode is next to no help, the mailing list seems to be unavailable.... the things people are saying about how I should "just switch" back to using pf seem like a drastic solution when people in #netfilter are so content (yet many of them have never heard of synproxy before.) Any thoughts on this are appreciated, -Paige From jtk at cymru.com Wed Oct 8 14:52:07 2014 From: jtk at cymru.com (John Kristoff) Date: Wed, 8 Oct 2014 09:52:07 -0500 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008144238.GE10316@Vurt.local> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> Message-ID: <20141008095207.284ab33d@localhost> On Wed, 8 Oct 2014 16:42:38 +0200 Job Snijders wrote: > Just like chicory, personally I don't like it. Yes, Cymru has build a > reputation as clearing house for redistribution of security related > information. But... (aside from any local safety net filter), it's > quite a leap to allow a single entity to inject blackholes for any > prefix. Hi Job, Thanks for your comments. I'm aware of some other projects, including another one, much more elaborate, talked about in another session at NANOG this week. Do note, UTRS does not allow a single entity to inject black holes for any prefix, only a limited number of /32's for their own prefixes. The presentation and the information page I linked to have some additional details. > IXPs could offer BGP or API triggered ACLs which are inserted into the > peering fabric and only affect the participant's peering port(s). This > way, any blackholing (either correctly applied or malicious) only > affects the initator of that blackhole and nobody else. Advantages are > that aclserver does not require peers to cooperate with each other and > no validation is required. I've heard of some IXPs recently offering this service, sounds great. It has also been suggested we might talk to ISPs how to RTBH to their customers and see if there was a way for those routes to be passed further along, perhaps to something like UTRS for further dissemination. I'm not sure that would work, but it was an interesting idea too. Thanks for your comments, John From rdobbins at arbor.net Wed Oct 8 14:54:10 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 8 Oct 2014 21:54:10 +0700 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: <54354D97.5010706@gmail.com> References: <54354D97.5010706@gmail.com> Message-ID: <158C57C2-2642-4736-A9D6-7C9C356C7A4B@arbor.net> On Oct 8, 2014, at 9:43 PM, Paige Thompson wrote: > Any thoughts on this are appreciated, pp. 30-36. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From Thijs.Stuurman at is.nl Wed Oct 8 15:06:26 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Wed, 8 Oct 2014 15:06:26 +0000 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: References: Message-ID: I set up a bridge at home to filter traffic using iptables with synproxy. I tried to adjust the lines so that it would log hits but that wouldn't work It gave me a message to read dmesg why it didn't work but dmesg had no information in it. However, when I turned on the lines in my iptables configuration file (bash script to load in the rules basicly) it did filter out a SYN attack and the output of "cat /proc/net/stat/synproxy" showed the syn_received go up. (see https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html) A tcpdump on the bridge confirmed the packets coming in and on my server behind it they didn't so that worked while I would perfectly fine access the apache service. I haven't done any further testing, just got the setup to work late last night. Kind regards / Vriendelijke groet, IS Group Thijs Stuurman Powered by results. Wielingenstraat 8 | T +31 (0)299 476 185 1441 ZR Purmerend | F +31 (0)299 476 288 http://www.is.nl | KvK Hoorn 36049256 IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified. -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Paige Thompson Verzonden: Wednesday, October 8, 2014 4:51 PM Aan: Nanog Onderwerp: netfilter/iptables synproxy; need help deciding Hi, I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of things to pick at but please try to focus on the subject of synproxy for the purpose of this e-mail.) based on the following table I want to say its not working because it seems to never change: http://pastie.org/private/xwct5opbb0aajcko2tnpw more info on /proc/stat/synproxy:http://www.spinics.net/lists/netdev/msg264350.html My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY I really would like to come to some closure on this subject. Whether it needs to be done right or not done at all, I'm tired of it looming over me. I really want to believe I should do the very best to have all mitigation techniques already in place, but I'm having a hard time understanding why this is next to impossible to figure out if it's so important. #netfilter on freenode is next to no help, the mailing list seems to be unavailable.... the things people are saying about how I should "just switch" back to using pf seem like a drastic solution when people in #netfilter are so content (yet many of them have never heard of synproxy before.) Any thoughts on this are appreciated, -Paige From paigeadele at gmail.com Wed Oct 8 15:13:47 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Wed, 08 Oct 2014 18:13:47 +0300 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: References: Message-ID: <543554AB.30700@gmail.com> On 10/08/14 18:06, Thijs Stuurman wrote: > I set up a bridge at home to filter traffic using iptables with synproxy. I tried to adjust the lines so that it would log hits but that wouldn't work > It gave me a message to read dmesg why it didn't work but dmesg had no information in it. > However, when I turned on the lines in my iptables configuration file (bash script to load in the rules basicly) it did filter out a SYN attack and the output of "cat /proc/net/stat/synproxy" showed the syn_received go up. (see https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html) > > A tcpdump on the bridge confirmed the packets coming in and on my server behind it they didn't so that worked while I would perfectly fine access the apache service. > > > I haven't done any further testing, just got the setup to work late last night. > > > Kind regards / Vriendelijke groet, > IS Group > Thijs Stuurman > > Powered by results. > > Wielingenstraat 8 | T +31 (0)299 476 185 > 1441 ZR Purmerend | F +31 (0)299 476 288 > http://www.is.nl | KvK Hoorn 36049256 > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, > ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified. > > -----Oorspronkelijk bericht----- > Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Paige Thompson > Verzonden: Wednesday, October 8, 2014 4:51 PM > Aan: Nanog > Onderwerp: netfilter/iptables synproxy; need help deciding > > Hi, > > I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. > I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. > pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of things to pick at but please try to focus on the subject of synproxy for the purpose of this e-mail.) > > based on the following table I want to say its not working because it seems to never change: > http://pastie.org/private/xwct5opbb0aajcko2tnpw > > more info on /proc/stat/synproxy:http://www.spinics.net/lists/netdev/msg264350.html > > My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: > http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY > > I really would like to come to some closure on this subject. Whether it needs to be done right or not done at all, I'm tired of it looming over me. I really want to believe I should do the very best to have all mitigation techniques already in place, but I'm having a hard time understanding why this is next to impossible to figure out if it's so important. #netfilter on freenode is next to no help, the mailing list seems to be unavailable.... the things people are saying about how I should "just switch" back to using pf seem like a drastic solution when people in #netfilter are so content (yet many of them have never heard of synproxy before.) > > > Any thoughts on this are appreciated, > > -Paige Yeah, I have no way to test for sure but I can tell you this which I forgot to mention: All of my services still work with these rules -A PREROUTING -d 172.16.20.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack -A PREROUTING -d 172.16.40.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack -A PREROUTING -d 172.16.80.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack None of my services worked with this rule: -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack I sort of get it, but I totally don't get it. I'm not sure what traffic that second rule is matching (or if the -d even works in the raw table maybe thats bunk too.) I don't think the first set are working, but I have no way to test it either. From Thijs.Stuurman at is.nl Wed Oct 8 15:16:02 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Wed, 8 Oct 2014 15:16:02 +0000 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: <54354D97.5010706@gmail.com> References: <54354D97.5010706@gmail.com> Message-ID: Sorry I am doing multiple things at once and my setup is at home... just a bit more information. I used a fresh latest version centos 7 installation for my bridge (3 nics, 2 in bridge). In my case the output of /proc/net/stat/synproxy you show on http://pastie.org/private/xwct5opbb0aajcko2tnpw did change the first number underneath syn_received. I don't believe any other value changed during my test syn flood (using hping from an external internet server to port 80 of the webserver behind the bridge). You may contact me off list if you wish more information about what I configured. Planning on testing a fullscale flood later this week but I currently lack hardware at home. Kind regards / Vriendelijke groet, IS Group Thijs Stuurman Powered by results. Wielingenstraat 8 | T +31 (0)299 476 185 1441 ZR Purmerend | F +31 (0)299 476 288 http://www.is.nl | KvK Hoorn 36049256 IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified. -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Paige Thompson Verzonden: Wednesday, October 8, 2014 4:44 PM Aan: nanog at nanog.org Onderwerp: netfilter/iptables synproxy; need help deciding Hi, I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of things to pick at but please try to focus on the subject of synproxy for the purpose of this e-mail.) based on the following table I want to say its not working because it seems to never change: http://pastie.org/private/xwct5opbb0aajcko2tnpw more info on /proc/stat/synproxy: http://www.spinics.net/lists/netdev/msg264350.html My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY I really would like to come to some closure on this subject. Whether it needs to be done right or not done at all, I'm tired of it looming over me. I really want to believe I should do the very best to have all mitigation techniques already in place, but I'm having a hard time understanding why this is next to impossible to figure out if it's so important. #netfilter on freenode is next to no help, the mailing list seems to be unavailable.... the things people are saying about how I should "just switch" back to using pf seem like a drastic solution when people in #netfilter are so content (yet many of them have never heard of synproxy before.) Any thoughts on this are appreciated, -Paige From bill at herrin.us Wed Oct 8 15:19:54 2014 From: bill at herrin.us (William Herrin) Date: Wed, 8 Oct 2014 11:19:54 -0400 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008144238.GE10316@Vurt.local> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> Message-ID: On Wed, Oct 8, 2014 at 10:42 AM, Job Snijders wrote: > Just like chicory, personally I don't like it. Yes, Cymru has build a > reputation as clearing house for redistribution of security related > information. But... (aside from any local safety net filter), it's quite > a leap to allow a single entity to inject blackholes for any prefix. Hi Job, We already do that on the /24 level... it's called "BGP" and we all have fun when a service provider in one of the 'Stans injects a route overriding Youtube. How could John's system do worse? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From Thijs.Stuurman at is.nl Wed Oct 8 15:21:33 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Wed, 8 Oct 2014 15:21:33 +0000 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: <543554AB.30700@gmail.com> References: <543554AB.30700@gmail.com> Message-ID: Try the examples given here: https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html Your line make no sense to me: """ -A PREROUTING -d 172.16.20.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack """ The first entry should register it in the raw table and this is for SYN only, RST, ACK etc' should be handled by an INVALID filter together with "sysctl -w net/netfilter/nf_conntrack_tcp_loose=0". So only for the SYN packets you configure the SYNPROXY as such: iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack iptables -I INPUT -p tcp -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 In my case I believe I adjusted the INPUT on the second line to FORWARD as my box functions as a bridge. I'll check and mail you when I get home. Kind regards / Vriendelijke groet, IS Group Thijs Stuurman Powered by results. Wielingenstraat 8 | T +31 (0)299 476 185 1441 ZR Purmerend | F +31 (0)299 476 288 http://www.is.nl | KvK Hoorn 36049256 IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified. -----Oorspronkelijk bericht----- Van: Paige Thompson [mailto:paigeadele at gmail.com] Verzonden: Wednesday, October 8, 2014 5:14 PM Aan: Thijs Stuurman; Nanog Onderwerp: Re: netfilter/iptables synproxy; need help deciding On 10/08/14 18:06, Thijs Stuurman wrote: > I set up a bridge at home to filter traffic using iptables with > synproxy. I tried to adjust the lines so that it would log hits but that wouldn't work It gave me a message to read dmesg why it didn't work but dmesg had no information in it. > However, when I turned on the lines in my iptables configuration file > (bash script to load in the rules basicly) it did filter out a SYN > attack and the output of "cat /proc/net/stat/synproxy" showed the > syn_received go up. (see > https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Us > ing-IPTables-SYNPROXY.html) > > A tcpdump on the bridge confirmed the packets coming in and on my server behind it they didn't so that worked while I would perfectly fine access the apache service. > > > I haven't done any further testing, just got the setup to work late last night. > > > Kind regards / Vriendelijke groet, > IS Group > Thijs Stuurman > > Powered by results. > > Wielingenstraat 8 | T +31 (0)299 476 185 > 1441 ZR Purmerend | F +31 (0)299 476 288 http://www.is.nl | KvK Hoorn > 36049256 > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE > 3402 en PCI DSS certified. > > -----Oorspronkelijk bericht----- > Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Paige Thompson > Verzonden: Wednesday, October 8, 2014 4:51 PM > Aan: Nanog > Onderwerp: netfilter/iptables synproxy; need help deciding > > Hi, > > I guess syncookies wasn't enough and the SYNPROXY target is a relatively new addition to netfilter. If I remember correctly this has been a part of BSD PF for quite some time and is pretty easy to get up and working. > I recently tried to set this up on one of my gateways considering that it's just one less uncovered means for somebody to be a dick that I have to deal with in the future. But, after spending some time researching and asking on Freenode I have been unable to determine whether or not it works, or even makes any sense. I'm starting to think it's a moot point. > pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty > of things to pick at but please try to focus on the subject of > synproxy for the purpose of this e-mail.) > > based on the following table I want to say its not working because it seems to never change: > http://pastie.org/private/xwct5opbb0aajcko2tnpw > > more info on > /proc/stat/synproxy:http://www.spinics.net/lists/netdev/msg264350.html > > My only guess is that you can't do this at all with NAT because it relies on conntrack or maybe it will only work with SNAT? I don't understand this well enough to say; are proper firewall rules really a science that need to be understood that far in depth? Why is this not documented? This tutorial seems to indicate that you could use this with a NAT'd network: > http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTable > s_SYNPROXY > > I really would like to come to some closure on this subject. Whether > it needs to be done right or not done at all, I'm tired of it looming > over me. I really want to believe I should do the very best to have > all mitigation techniques already in place, but I'm having a hard time > understanding why this is next to impossible to figure out if it's so > important. #netfilter on freenode is next to no help, the mailing list > seems to be unavailable.... the things people are saying about how I > should "just switch" back to using pf seem like a drastic solution > when people in #netfilter are so content (yet many of them have never > heard of synproxy before.) > > > Any thoughts on this are appreciated, > > -Paige Yeah, I have no way to test for sure but I can tell you this which I forgot to mention: All of my services still work with these rules -A PREROUTING -d 172.16.20.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack -A PREROUTING -d 172.16.40.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack -A PREROUTING -d 172.16.80.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack None of my services worked with this rule: -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack I sort of get it, but I totally don't get it. I'm not sure what traffic that second rule is matching (or if the -d even works in the raw table maybe thats bunk too.) I don't think the first set are working, but I have no way to test it either. From paigeadele at gmail.com Wed Oct 8 15:24:32 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Wed, 08 Oct 2014 18:24:32 +0300 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: <158C57C2-2642-4736-A9D6-7C9C356C7A4B@arbor.net> References: <54354D97.5010706@gmail.com> <158C57C2-2642-4736-A9D6-7C9C356C7A4B@arbor.net> Message-ID: <54355730.9010907@gmail.com> On 10/08/14 17:54, Roland Dobbins wrote: > On Oct 8, 2014, at 9:43 PM, Paige Thompson wrote: > >> Any thoughts on this are appreciated, > > > pp. 30-36. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > Re pp: 30-36 I think I catch your drift (ie: using cisco netflow to detect a synflood?) but would you care to summarize just in case because I am not this savvy, but would like to understand. Also in regards to snort inline, I've been trying to figure out whether or not Snort/DAQ/NFQ (netfilter) is appropriate or not. I cannot get this to work but it seems like on a gatway, for example where I have all of this iptables stuff that NFQ would be appropriate and would probably help with all of the false positives (3 way handshake and a couple of others) I see when trying to use the pcap driver (the only one that will work.) From rdobbins at arbor.net Wed Oct 8 15:35:51 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 8 Oct 2014 22:35:51 +0700 Subject: netfilter/iptables synproxy; need help deciding In-Reply-To: <54355730.9010907@gmail.com> References: <54354D97.5010706@gmail.com> <158C57C2-2642-4736-A9D6-7C9C356C7A4B@arbor.net> <54355730.9010907@gmail.com> Message-ID: <1C2679CB-F14E-4051-A76A-B112AC00F051@arbor.net> On Oct 8, 2014, at 10:24 PM, Paige Thompson wrote: > Re pp: 30-36 I think I catch your drift (ie: using cisco netflow to detect a synflood?) but would you care to summarize just in case because > I am not this savvy, but would like to understand. Yes, you can do that - there are plenty of open-source tools out there. But pay attention to the infrastructure and host BCPs in that preso, as well. > Also in regards to snort inline, I've been trying to figure out whether or not Snort/DAQ/NFQ (netfilter) is appropriate or not. Yes, you can use it as a super-ACL. Beyond that, reverse-proxy caches are useful, as well, as noted in the cited historical email. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From johnl at iecc.com Wed Oct 8 16:02:21 2014 From: johnl at iecc.com (John Levine) Date: 8 Oct 2014 16:02:21 -0000 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008144238.GE10316@Vurt.local> Message-ID: <20141008160221.3424.qmail@ary.lan> >information. But... (aside from any local safety net filter), it's quite >a leap to allow a single entity to inject blackholes for any prefix. Spamhaus has been distributing their DROP list by BGP for years. The world hasn't ended, and I can't recall the last time it had a plausible false positive. http://www.spamhaus.org/drop/ R's, John From job at instituut.net Wed Oct 8 16:10:37 2014 From: job at instituut.net (Job Snijders) Date: Wed, 8 Oct 2014 18:10:37 +0200 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008160221.3424.qmail@ary.lan> References: <20141008144238.GE10316@Vurt.local> <20141008160221.3424.qmail@ary.lan> Message-ID: <20141008161037.GK10316@Vurt.local> On Wed, Oct 08, 2014 at 04:02:21PM -0000, John Levine wrote: > >information. But... (aside from any local safety net filter), it's quite > >a leap to allow a single entity to inject blackholes for any prefix. > > Spamhaus has been distributing their DROP list by BGP for years. The > world hasn't ended, and I can't recall the last time it had a > plausible false positive. The Spamhaus context is different: I know people take that DROP BGP feed and converting it into ACLs applicable locally on their mailservers, I don't know of people injecting these prefixes straight into the core. Kind regards, Job From snar at snar.spb.ru Wed Oct 8 16:44:19 2014 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Wed, 8 Oct 2014 20:44:19 +0400 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008144238.GE10316@Vurt.local> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> Message-ID: <20141008164419.GA28811@snar.spb.ru> On Wed, Oct 08, 2014 at 04:42:38PM +0200, Job Snijders wrote: > > There are various flavors at the moment in terms of validation (please > correct me if I am wrong): The Polish blackholing project only allows > blackholes which fall within the set of prefixes which an ASN > originates, the DE-CIX BS service accepts anything that is a subset of > your AS-SET. There is also "dynamic validation" approach: blackhole route is considered valid for injection if and only if there is a covering less-specific route with the best-path pointing to the same exit point as blackhole route. (definition of "exit point" can vary from "next ASn is the same we received blackhole from" to "both as-path and next-hops must be the same and aggregate route must be marked as customer's one"). This approach has its downside too: it requires you to run task-specific bgp speaker. Worse yet, usually you have to write that speaker :) -- In theory, there is no difference between theory and practice. But, in practice, there is. From bill at herrin.us Wed Oct 8 18:45:25 2014 From: bill at herrin.us (William Herrin) Date: Wed, 8 Oct 2014 14:45:25 -0400 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008085900.3b6f2a24@localhost> References: <20141008085900.3b6f2a24@localhost> Message-ID: On Wed, Oct 8, 2014 at 9:59 AM, John Kristoff wrote: > If you think this is a terrible idea and want to express all that is > wrong with it, tell me that too, I can take it. Hi John, It's a good idea, I think, but it has a problem: it's an escalation in an arms race that doesn't end well for the blue team. If we ever get good at keeping traffic to a single IP far enough away to not cripple us, the attacker need only spray the /24. Or spray our entire address space, easily identifiable from our BGP announcement. All this effort on our end and it took the attacker 15 minutes to modify his code. Two general types of DDOS traffic: botnets and forged source addresses. For the botnets, lots of real machines, each with a legitimate source IP address, we need to get to a router interface as close to each source address as we can get. Then temporarily shut down traffic from that source address crossing that link until the data flow suggests the problem traffic has ceased. Even if we have to pay the ISP who owns that link to do it for us. Quickly find it with automation. Quickly authenticate the attack flow. Quickly pay for remediation. For the address forgers, we need some kind of public detection system where ISPs who care provide the trace tools that let us figure out where the rogue attacking our network is _actually_ coming from. After which we can pay the ISP to interdict any traffic destined for anywhere in our network which enters from that link. Quickly with automation We can't win the arms race based on the destination; we'll only win it if we find a way to zero in on and interdict the source. Regards, Bill Herrin P.S. Also worth noting that paying a DDOS mitigation service can already accomplish the best-case result from something like UTRS. The mitigator announces the affected /24, sinks the attacked IP address and tunnels the rest of the packets back to us. Expensive but easy peasy. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From mpetach at netflight.com Wed Oct 8 20:19:05 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 8 Oct 2014 13:19:05 -0700 Subject: 2014.10.08 NANOG62 notes Message-ID: So, I suspect I'm going to spend a little time tonight renaming the files to make more sense; I'm uploading the rest of my notes now to http://nanog.cluepon.net/index.php/NANOG62 but you should probably ignore the more specific links I sent out earlier, as those will end up changing. Starting from that top-level-page will definitely still work, though, and then you can just click on the talk you want from there. Thanks everyone for coming--this has been an absolutely whirlwind conference this time around! Thanks! Matt From larrysheldon at cox.net Wed Oct 8 20:29:39 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 08 Oct 2014 15:29:39 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0dnv1p01507cg5T01dnwJd> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <0dnv1p01507cg5T01dnwJd> Message-ID: <54359EB3.9090909@cox.net> On 10/8/2014 08:47, William Herrin wrote: > On Wed, Oct 8, 2014 at 8:42 AM, Roy wrote: >> On 10/7/2014 10:35 PM, Larry Sheldon wrote: >>> On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: >>>> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >>>>> The cell service is not a requirement placed upon them, I am pretty >>>>> sure. >>>> >>>> However, once having chosen to provide it, and thus create an expectation >>>> that cellular E911 is available, they're obligated to carry through on >>>> that. >>>> >>> Obligated by what law, regulation, rule or contract? >> >> Obligated by the FCC license > > Hi Larry, Roy: > > BART would not have had an FCC license. They'd have had contracts with > the various phone companies to co-locate equipment and provide wired > backhaul out of the tunnels. The only thing they'd be guilty of is > breach of contract, and that only if the cell phone companies decided > their behavior was inconsistent with the SLA.. OK that makes more sense than the private answer I got from Roy. I wondered why the FCC didn't take action if there was a license violation. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From joelja at bogus.com Wed Oct 8 20:37:39 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 08 Oct 2014 13:37:39 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54359EB3.9090909@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <0dnv1p01507cg5T01dnwJd> <54359EB3.9090909@cox.net> Message-ID: <5435A093.5070501@bogus.com> On 10/8/14 1:29 PM, Larry Sheldon wrote: > On 10/8/2014 08:47, William Herrin wrote: >> On Wed, Oct 8, 2014 at 8:42 AM, Roy wrote: >>> On 10/7/2014 10:35 PM, Larry Sheldon wrote: >>>> On 10/7/2014 23:44, Valdis.Kletnieks at vt.edu wrote: >>>>> On Tue, 07 Oct 2014 23:10:15 -0500, Larry Sheldon said: >>>>>> The cell service is not a requirement placed upon them, I am pretty >>>>>> sure. >>>>> >>>>> However, once having chosen to provide it, and thus create an >>>>> expectation >>>>> that cellular E911 is available, they're obligated to carry through on >>>>> that. >>>>> >>>> Obligated by what law, regulation, rule or contract? >>> >>> Obligated by the FCC license >> >> Hi Larry, Roy: >> >> BART would not have had an FCC license. They'd have had contracts with >> the various phone companies to co-locate equipment and provide wired >> backhaul out of the tunnels. The only thing they'd be guilty of is >> breach of contract, and that only if the cell phone companies decided >> their behavior was inconsistent with the SLA.. > > OK that makes more sense than the private answer I got from Roy. I > wondered why the FCC didn't take action if there was a license violation. http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Wed Oct 8 21:11:34 2014 From: bill at herrin.us (William Herrin) Date: Wed, 8 Oct 2014 17:11:34 -0400 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <5435A093.5070501@bogus.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> Message-ID: On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: > On 10/8/14 1:29 PM, Larry Sheldon wrote: >> On 10/8/2014 08:47, William Herrin wrote: >>> BART would not have had an FCC license. They'd have had contracts with >>> the various phone companies to co-locate equipment and provide wired >>> backhaul out of the tunnels. The only thing they'd be guilty of is >>> breach of contract, and that only if the cell phone companies decided >>> their behavior was inconsistent with the SLA.. >> >> OK that makes more sense than the private answer I got from Roy. I >> wondered why the FCC didn't take action if there was a license violation. > > http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 >From the article: "Among the issues on which the F.C.C. is seeking comment is whether it even has authority over the issue." Also: "The BART system owns the wireless transmitters and receivers that allow for cellphone reception within its network." I'm not entirely clear how that works. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From ktims at stargate.ca Wed Oct 8 21:17:23 2014 From: ktims at stargate.ca (Keenan Tims) Date: Wed, 08 Oct 2014 14:17:23 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> Message-ID: <5435A9E3.3000001@stargate.ca> There is a provision in the regulations somewhere that allows underground/tunnel transmitters on licensed bands without a license, provided certain power limits are honoured outside of the tunnel. Perhaps they are operating under these provisions? K On 10/08/2014 02:11 PM, William Herrin wrote: > On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>> On 10/8/2014 08:47, William Herrin wrote: >>>> BART would not have had an FCC license. They'd have had contracts with >>>> the various phone companies to co-locate equipment and provide wired >>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>> breach of contract, and that only if the cell phone companies decided >>>> their behavior was inconsistent with the SLA.. >>> >>> OK that makes more sense than the private answer I got from Roy. I >>> wondered why the FCC didn't take action if there was a license violation. >> >> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 > > From the article: "Among the issues on which the F.C.C. is seeking > comment is whether it even has authority over the issue." > > Also: "The BART system owns the wireless transmitters and receivers > that allow for cellphone reception within its network." > > I'm not entirely clear how that works. > > Regards, > Bill Herrin > > > From brandonwade at yahoo.com Wed Oct 8 20:44:07 2014 From: brandonwade at yahoo.com (Brandon Wade) Date: Wed, 8 Oct 2014 13:44:07 -0700 Subject: RADB Message-ID: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> Hi, I really don't know where else to post this. I recently subscribed to RADB and added route objects and route6 objects for our prefixes we announce. Of course an aut-num object was created and I created a list of ASN's that are downstream customers in an as-set list. But, since this is my first time ever subscribing to a routing registry, I really don't know for sure that I'm doing everything correctly. So, I submitted an e-mail to RADB and requested that they review what I've done and to see if I'm doing it correctly. Well, the reply I received was far less than I could have ever imagined: "RADb is a self-serve service. If you have specific questions, we can address those. However, the type of audit requested is not a part of the standard offering associated with this service." So my question is, how am I supposed to verify that what I've done is what is supposed to be done and that I am doing this correctly? My next question is, why would RADB offer zero support for confirming this? And lastly, why should my organization pay $500 per year to a service that is unwilling to assist in making sure their subscriber is using their service properly? Best regards, Brandon Wade From nick at foobar.org Wed Oct 8 22:11:49 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 08 Oct 2014 23:11:49 +0100 Subject: RADB In-Reply-To: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> Message-ID: <5435B6A5.40200@foobar.org> On 08/10/2014 21:44, Brandon Wade wrote: > My next question is, why would RADB offer zero support for confirming > this? And lastly, why should my organization pay $500 per year to a > service that is unwilling to assist in making sure their subscriber is > using their service properly? radb.net checks for syntactic correctness of database objects. Semantic analysis is network dependent and is outside the scope of what the RADB staff can provide. If you need this, you should hire someone who understands your network and who can determine whether your irrdb objects are a reasonable representation of your routing policy. Nick From larrysheldon at cox.net Wed Oct 8 22:25:33 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 08 Oct 2014 17:25:33 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0lBy1p00o07cg5T01lBzZ4> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0lBy1p00o07cg5T01lBzZ4> Message-ID: <5435B9DD.7060906@cox.net> On 10/8/2014 16:11, William Herrin wrote: > On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>> On 10/8/2014 08:47, William Herrin wrote: >>>> BART would not have had an FCC license. They'd have had contracts with >>>> the various phone companies to co-locate equipment and provide wired >>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>> breach of contract, and that only if the cell phone companies decided >>>> their behavior was inconsistent with the SLA.. >>> >>> OK that makes more sense than the private answer I got from Roy. I >>> wondered why the FCC didn't take action if there was a license violation. >> >> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 > >>From the article: "Among the issues on which the F.C.C. is seeking > comment is whether it even has authority over the issue." > > Also: "The BART system owns the wireless transmitters and receivers > that allow for cellphone reception within its network." > > I'm not entirely clear how that works. Several things fail the "entirely clear" test. (I'm not entirely clear on where the interruption was, but the pictures made me think "San Francisco". And I'm too lazy to look it up.) In San Francisco, the Muni is in a pipe above (if I remember correctly) BART--did they interrupt cell service there as well? I wonder if there is any leakage. As I recall, BART does not permit anything on their trains--water, baby bottles, and I thought radios. How do they get the authority to do that? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Wed Oct 8 22:31:26 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 08 Oct 2014 17:31:26 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0lJK1p0081cZc5601lJLoU> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0lJK1p0081cZc5601lJLoU> Message-ID: <5435BB3E.3040807@cox.net> On 10/8/2014 16:17, Keenan Tims wrote: > There is a provision in the regulations somewhere that allows > underground/tunnel transmitters on licensed bands without a license, > provided certain power limits are honoured outside of the tunnel. > Perhaps they are operating under these provisions? Which, if unlicensed, brings us back to the question of "by what authority, other than popular rioter opinion, are they REQUIRED to provide the service?". -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From owen at delong.com Wed Oct 8 22:39:10 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Oct 2014 15:39:10 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> Message-ID: On Oct 7, 2014, at 6:10 PM, Jimmy Hess wrote: > On Tue, Oct 7, 2014 at 7:43 PM, Keenan Tims wrote: >> I don't think it changes much. Passive methods (ie. Faraday cage) would >> likely be fine, as would layer 8 through 10 methods. > > Well... actually... passive methods are probably fine, as long as > they are not breaking reception to nearby properties, BUT it might > result in some proceedings or investigations regarding anticompetitive > behaviors --- also, if there are other businesses nearby, it could > lead to some objections when you go seeking permits to build this > giant faraday cage. The local authorities might eventually require > some modifications. :) Actually, if you turn your building into a faraday cage, I’m not sure there’s any legal basis on which to tell you that you have to permit RF through, even if it blocks the signal downstream. Creating a shadow is very different from actively emitting “harmful interference” and I don’t know of any laws or regulations which could be used to prevent you from doing so. Owen From owen at delong.com Wed Oct 8 22:41:53 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Oct 2014 15:41:53 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <35458.1412732186@turing-police.cc.vt.edu> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> Message-ID: <6A7EC40F-0340-466C-BA81-86B90A67B0F5@delong.com> On Oct 7, 2014, at 6:36 PM, valdis.kletnieks at vt.edu wrote: > On Tue, 07 Oct 2014 20:10:44 -0500, Jimmy Hess said: > >> The only way to legally block cell phone RF would likely be on behalf >> of the licensee ---- In other words, possibly, persuade the cell >> phone companies to allow this, then create an approved "special" >> local cell tower all their phones in the same building will by >> default connect to in preference to any other, which will also not >> receive any calls or messages or allow any to be sent. > > I wonder how many customers the cell phone company will attract by doing that. > BART experimented with something even safer than this (hosting provider microcells in the underground bart stations on the condition that bart could cut them off when they determined it was “in the interest of public safety”). The first time BART exercised this “turn-off” capability, it drew quite a bit of fire from a number of directions and complaints were lodged with the FCC. FCC doesn’t appear to have made any ruling on the matter as yet (at least none that I could find), but the wording of the various initial responses definitely didn’t seem to favor the idea of allowing cellular service disruption at the whim of a local transit agency. Owen From cgucker at onesc.net Wed Oct 8 23:15:54 2014 From: cgucker at onesc.net (Charles Gucker) Date: Wed, 8 Oct 2014 19:15:54 -0400 Subject: RADB In-Reply-To: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> Message-ID: You can also verify the object configurations from another IRRd, such as Level(3) whois -h filtergen.level3.net "RADB::YOUR-AS-SET -searchpath=RIPE;ARIN;RADB -recurseok -warnonly" You can limit the searchpath to just include RADB if you wish, but it's good to know what else is out there. charles On Wed, Oct 8, 2014 at 4:44 PM, Brandon Wade wrote: > Hi, > > I really don't know where else to post this. I recently subscribed to RADB and added route objects and route6 objects for our prefixes we announce. Of course an aut-num object was created and I created a list of ASN's that are downstream customers in an as-set list. But, since this is my first time ever subscribing to a routing registry, I really don't know for sure that I'm doing everything correctly. So, I submitted an e-mail to RADB and requested that they review what I've done and to see if I'm doing it correctly. Well, the reply I received was far less than I could have ever imagined: > > "RADb is a self-serve service. If you have specific questions, we can > address those. However, the type of audit requested is not a part of the standard offering associated with this service." > > So my question is, how am I supposed to verify that what I've done is what is supposed to be done and that I am doing this correctly? > > My next question is, why would RADB offer zero support for confirming this? And lastly, why should my organization pay $500 per year to a service that is unwilling to assist in making sure their subscriber is using their service properly? > > Best regards, > Brandon Wade From faisal at snappytelecom.net Thu Oct 9 01:15:03 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 01:15:03 +0000 (GMT) Subject: RADB In-Reply-To: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> Message-ID: <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd.. So the real question Brandon is asking.. For a newbie, how does one go about learning the basic's of IRRd. Speaking for myself, if there is a good answer, I would welcome it. Here is what I had to do... 1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource. 2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc. 3. Did Google searches on finding some of the older NANOG presentations about IRRd. Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Brandon Wade" > To: nanog at nanog.org > Sent: Wednesday, October 8, 2014 4:44:07 PM > Subject: RADB > > Hi, > > I really don't know where else to post this. I recently subscribed to RADB > and added route objects and route6 objects for our prefixes we announce. Of > course an aut-num object was created and I created a list of ASN's that are > downstream customers in an as-set list. But, since this is my first time > ever subscribing to a routing registry, I really don't know for sure that > I'm doing everything correctly. So, I submitted an e-mail to RADB and > requested that they review what I've done and to see if I'm doing it > correctly. Well, the reply I received was far less than I could have ever > imagined: > > "RADb is a self-serve service. If you have specific questions, we can > address those. However, the type of audit requested is not a part of the > standard offering associated with this service." > > So my question is, how am I supposed to verify that what I've done is what is > supposed to be done and that I am doing this correctly? > > My next question is, why would RADB offer zero support for confirming this? > And lastly, why should my organization pay $500 per year to a service that > is unwilling to assist in making sure their subscriber is using their > service properly? > > Best regards, > Brandon Wade > From ESundberg at nitelusa.com Thu Oct 9 01:18:16 2014 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 9 Oct 2014 01:18:16 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out Message-ID: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. /64 /60 /56 /48 Small Customer? Medium Customer? Large Customer? Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From marka at isc.org Thu Oct 9 01:31:15 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 12:31:15 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 01:18:16 -0000." <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <20141009013115.CDFBF2116E22@rock.dv.isc.org> Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste!!!! It will also reduce the number of exceptions you need to process and make over all administration easier. As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. Mark In message <495D0934DA46854A9CA758393724D5906DA244 at NI-MAIL02.nii.ads>, Erik Sun dberg writes: > I am planning out our IPv6 deployment right now and I am trying to figure o= > ut our default allocation for customer LAN blocks. So what is everyone givi= > ng for a default LAN allocation for IPv6 Customers. I guess the idea of ha= > nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cring= > e at the waste. Especially when you know 90% of customers will never have m= > ore than 2 or 3 subnets. As I see it the customer can always ask for more I= > Pv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = > or previous e-mail messages attached to it may contain confidential informa= > tion that is legally privileged. If you are not the intended recipient, or = > a person responsible for delivering it to the intended recipient, you are h= > ereby notified that any disclosure, copying, distribution or use of any of = > the information contained in or attached to this transmission is STRICTLY P= > ROHIBITED. If you have received this transmission in error please notify th= > e sender immediately by replying to this e-mail. You must destroy the origi= > nal transmission and its attachments without reading or saving in any manne= > r. Thank you. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From markjr at easydns.com Thu Oct 9 01:52:18 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Wed, 08 Oct 2014 21:52:18 -0400 Subject: verizon postmaster here? Message-ID: <5435EA52.5070304@easydns.com> Hi, is there a verizon postmaster around who could contact me off-list? thx -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From mprice at tqhosting.com Thu Oct 9 02:20:16 2014 From: mprice at tqhosting.com (Mark Price) Date: Wed, 8 Oct 2014 22:20:16 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: There seem to be lots of various opinions still on this subject. What type of customer are you dealing with, what service are they receiving? We are allocating a /64 per customer (VPS / dedicated server / small co-lo) but doing them on /56 boundaries so that we can easily expand their allocation if needed, as well as back-fill more /64 allocations in that address space. Mark On Wed, Oct 8, 2014 at 9:18 PM, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure > out our default allocation for customer LAN blocks. So what is everyone > giving for a default LAN allocation for IPv6 Customers. I guess the idea > of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > cringe at the waste. Especially when you know 90% of customers will never > have more than 2 or 3 subnets. As I see it the customer can always ask for > more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From drc at virtualized.org Thu Oct 9 02:21:00 2014 From: drc at virtualized.org (David Conrad) Date: Wed, 8 Oct 2014 19:21:00 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <44A2046F-4961-4E64-8FF1-72D1242C5DEE@virtualized.org> Erik, On Oct 8, 2014, at 6:18 PM, Erik Sundberg wrote: > I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Don’t cringe. Yeah, a /48 is a crazy amount of space, but that isn’t the resource we are likely to ever need to conserve in the lifetime of IPv6 (well, modulo insane allocation policies the RIR communities could potentially create, but hopefully rational folks will stop that. Hopefully). If you’re concerned, do the math: e.g., assume a couple of orders of magnitude more allocations per year than the current IPv4 burn rate, assume an IPv6 /48 = an IPv4 /32 and then see how many decades the existing /3 of global unicast IPv6 will last. The real issue is how we’re going to scale routing. Allocating /48s to all your customers out of your /32 (or /28 or whatever the default ISP allocation is this week) won’t affect that in any significant way. And besides, allocating all your customers a standard size should make your provisioning systems a lot easier, allowing you to conserve what’s really important... Regards, -drc From bill at herrin.us Thu Oct 9 02:32:29 2014 From: bill at herrin.us (William Herrin) Date: Wed, 8 Oct 2014 22:32:29 -0400 Subject: speaking of wifi Message-ID: Speaking of wifi and the NANOG conference that just finished in Baltimore, we have some words from Maryland Governor Martin O'Malley: http://www.washingtonpost.com/blogs/the-fix/wp/2014/10/08/martin-omalley-and-the-human-right-to-wifi/ -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From brandonwade at yahoo.com Thu Oct 9 02:35:37 2014 From: brandonwade at yahoo.com (Brandon Wade) Date: Wed, 8 Oct 2014 19:35:37 -0700 Subject: RADB In-Reply-To: <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> Message-ID: <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> >> For a newbie, how does one go about learning the basic's of IRRd. That pretty much sums it up. I feel like I'm stuck reading RFC's that are too overly complex for something that seems like it shouldn't be complex. Anyone know of a quick 101 intro to routing registries with a simple example of an AS that has two upstream providers and a handful of peers and downstream AS's? Brandon On Wednesday, October 8, 2014 8:15 PM, Faisal Imtiaz wrote: I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd.. So the real question Brandon is asking.. For a newbie, how does one go about learning the basic's of IRRd. Speaking for myself, if there is a good answer, I would welcome it. Here is what I had to do... 1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource. 2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc. 3. Did Google searches on finding some of the older NANOG presentations about IRRd. Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Brandon Wade" > To: nanog at nanog.org > Sent: Wednesday, October 8, 2014 4:44:07 PM > Subject: RADB > > Hi, > > I really don't know where else to post this. I recently subscribed to RADB > and added route objects and route6 objects for our prefixes we announce. Of > course an aut-num object was created and I created a list of ASN's that are > downstream customers in an as-set list. But, since this is my first time > ever subscribing to a routing registry, I really don't know for sure that > I'm doing everything correctly. So, I submitted an e-mail to RADB and > requested that they review what I've done and to see if I'm doing it > correctly. Well, the reply I received was far less than I could have ever > imagined: > > "RADb is a self-serve service. If you have specific questions, we can > address those. However, the type of audit requested is not a part of the > standard offering associated with this service." > > So my question is, how am I supposed to verify that what I've done is what is > supposed to be done and that I am doing this correctly? > > My next question is, why would RADB offer zero support for confirming this? > And lastly, why should my organization pay $500 per year to a service that > is unwilling to assist in making sure their subscriber is using their > service properly? > > Best regards, > Brandon Wade > From james.cutler at consultant.com Thu Oct 9 02:48:48 2014 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 8 Oct 2014 22:48:48 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> On Oct 8, 2014, at 9:18 PM, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > Erik, Selection of a default prefix is easy. Here are the steps. 1. Design your address allocation systems using /48. 2. Estimate your ongoing address management costs using /48. 3. For each +4 in prefix length, estimate doubling your long term address management costs. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.2 Your customers want working Internet connections 4.3 You want income at a minimum of ongoing expense make a sensible business decision. Easy-peasy. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From contact at winterei.se Thu Oct 9 02:53:40 2014 From: contact at winterei.se (Paul S.) Date: Thu, 09 Oct 2014 11:53:40 +0900 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <5435F8B4.20809@winterei.se> I'm allocating /64s in /56 boundaries per customer. Allows me to give the client more should they need it without fuss. On 10/9/2014 午前 10:18, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From faisal at snappytelecom.net Thu Oct 9 03:37:35 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 03:37:35 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> We are going thru a similar process.. from all of my reading, best practice discussions etc.. Here is what i have understood so far:- Residential Customers: /64 Small & Medium size Business Customers: /56 Large Business size or a multi-location Business Customer: /48 Don't skimp on allocating the subnets like we do on IPv4 Better to be 'wasteful' than have to come back to re-number or re-allocate . Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Erik Sundberg" > To: nanog at nanog.org > Sent: Wednesday, October 8, 2014 9:18:16 PM > Subject: IPv6 Default Allocation - What size allocation are you giving out > > I am planning out our IPv6 deployment right now and I am trying to figure out > our default allocation for customer LAN blocks. So what is everyone giving > for a default LAN allocation for IPv6 Customers. I guess the idea of > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > cringe at the waste. Especially when you know 90% of customers will never > have more than 2 or 3 subnets. As I see it the customer can always ask for > more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or > previous e-mail messages attached to it may contain confidential information > that is legally privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any of > the information contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error please notify > the sender immediately by replying to this e-mail. You must destroy the > original transmission and its attachments without reading or saving in any > manner. Thank you. > From marka at isc.org Thu Oct 9 03:43:05 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 14:43:05 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 03:37:35 -0000." <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141009034305.365FC212CDAD@rock.dv.isc.org> In message <126729399.131320.1412825855138.JavaMail.zimbra at snappytelecom.net>, Faisal Imtiaz writes: > We are going thru a similar process.. from all of my reading, best practice d > iscussions etc.. > > Here is what i have understood so far:- > > Residential Customers: /64 NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > Small & Medium size Business Customers: /56 > > Large Business size or a multi-location Business Customer: /48 > > Don't skimp on allocating the subnets like we do on IPv4 > Better to be 'wasteful' than have to come back to re-number or re-allocate . > > Regards > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Erik Sundberg" > > To: nanog at nanog.org > > Sent: Wednesday, October 8, 2014 9:18:16 PM > > Subject: IPv6 Default Allocation - What size allocation are you giving out > > > > I am planning out our IPv6 deployment right now and I am trying to figure o > ut > > our default allocation for customer LAN blocks. So what is everyone giving > > for a default LAN allocation for IPv6 Customers. I guess the idea of > > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > > cringe at the waste. Especially when you know 90% of customers will never > > have more than 2 or 3 subnets. As I see it the customer can always ask for > > more IPv6 Space. > > > > /64 > > /60 > > /56 > > /48 > > > > Small Customer? > > Medium Customer? > > Large Customer? > > > > Thanks > > > > Erik > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or > > previous e-mail messages attached to it may contain confidential informatio > n > > that is legally privileged. If you are not the intended recipient, or a > > person responsible for delivering it to the intended recipient, you are > > hereby notified that any disclosure, copying, distribution or use of any of > > the information contained in or attached to this transmission is STRICTLY > > PROHIBITED. If you have received this transmission in error please notify > > the sender immediately by replying to this e-mail. You must destroy the > > original transmission and its attachments without reading or saving in any > > manner. Thank you. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sam.silvester at gmail.com Thu Oct 9 03:47:01 2014 From: sam.silvester at gmail.com (Sam Silvester) Date: Thu, 9 Oct 2014 14:17:01 +1030 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> Message-ID: Why would you only allocate a residential customer a single /64? That's totally short sighted in my view. On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz wrote: > We are going thru a similar process.. from all of my reading, best > practice discussions etc.. > > Here is what i have understood so far:- > > Residential Customers: /64 > > Small & Medium size Business Customers: /56 > > Large Business size or a multi-location Business Customer: /48 > > Don't skimp on allocating the subnets like we do on IPv4 > Better to be 'wasteful' than have to come back to re-number or re-allocate > . > > Regards > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Erik Sundberg" > > To: nanog at nanog.org > > Sent: Wednesday, October 8, 2014 9:18:16 PM > > Subject: IPv6 Default Allocation - What size allocation are you giving > out > > > > I am planning out our IPv6 deployment right now and I am trying to > figure out > > our default allocation for customer LAN blocks. So what is everyone > giving > > for a default LAN allocation for IPv6 Customers. I guess the idea of > > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > > cringe at the waste. Especially when you know 90% of customers will never > > have more than 2 or 3 subnets. As I see it the customer can always ask > for > > more IPv6 Space. > > > > /64 > > /60 > > /56 > > /48 > > > > Small Customer? > > Medium Customer? > > Large Customer? > > > > Thanks > > > > Erik > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or > > previous e-mail messages attached to it may contain confidential > information > > that is legally privileged. If you are not the intended recipient, or a > > person responsible for delivering it to the intended recipient, you are > > hereby notified that any disclosure, copying, distribution or use of any > of > > the information contained in or attached to this transmission is STRICTLY > > PROHIBITED. If you have received this transmission in error please notify > > the sender immediately by replying to this e-mail. You must destroy the > > original transmission and its attachments without reading or saving in > any > > manner. Thank you. > > > From gary.buhrmaster at gmail.com Thu Oct 9 03:48:51 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 9 Oct 2014 03:48:51 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: On Thu, Oct 9, 2014 at 1:18 AM, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. A /48. There is waste, and there is waste. A /48 is not really significant "waste" because IPv6 address space is so large. If one believes in the truly connected home or enterprise, there will be a number of customer internal device delegations. Avoid having to renumber your customers when they do those internal networks of networks (yes, there are ways to do it "transparently", but not having to do it means you avoid the pain of the "transparent", which may not be "transparent" at all). As a residential customer, those that are handing me smaller blocks seem to be planning to charge extra for larger prefixes as a revenue stream (I presume just like one got a single IPv4 address, but could pay for more, now you get either a /64 or a /60, and get to pay for more for a /56 or /48). I consider that short sighted from a customer centric viewpoint, but I can see the revenue stream viewpoint. So, the only reason not to provide a /48 is if you think it is in your business plan to charge by the address (and hope your viable competitors in your market space follow a similar strategy, for I would always choose a provider that offers me more for the same, or less, money; I can even hear your competitors sales reps spiel "Why build for obsolescence, we provide you all the space you will ever need at the same price and service level....". From tagno25 at gmail.com Thu Oct 9 03:54:36 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Wed, 8 Oct 2014 22:54:36 -0500 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> Message-ID: You should probably increase those allocations. Residential & Small Business Customers: /56 Medium & Large size Business Customers: /48 Multi-location Business Customer: /48 per site On Wed, Oct 8, 2014 at 10:37 PM, Faisal Imtiaz wrote: > We are going thru a similar process.. from all of my reading, best practice discussions etc.. > > Here is what i have understood so far:- > > Residential Customers: /64 > > Small & Medium size Business Customers: /56 > > Large Business size or a multi-location Business Customer: /48 > > Don't skimp on allocating the subnets like we do on IPv4 > Better to be 'wasteful' than have to come back to re-number or re-allocate . > > Regards > > > Faisal Imtiaz > Snappy Internet & Telecom From faisal at snappytelecom.net Thu Oct 9 04:07:09 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:07:09 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> Message-ID: <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct.... I don't have a reason for why a /64 as much as I also don't have any reason Why NOT.... So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Sam Silvester" > To: "Faisal Imtiaz" > Cc: "Erik Sundberg" , "NANOG" > Sent: Wednesday, October 8, 2014 11:47:01 PM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving > out > Why would you only allocate a residential customer a single /64? > That's totally short sighted in my view. > On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: > > We are going thru a similar process.. from all of my reading, best practice > > discussions etc.. > > > Here is what i have understood so far:- > > > Residential Customers: /64 > > > Small & Medium size Business Customers: /56 > > > Large Business size or a multi-location Business Customer: /48 > > > Don't skimp on allocating the subnets like we do on IPv4 > > > Better to be 'wasteful' than have to come back to re-number or re-allocate > > . > > > Regards > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > > ----- Original Message ----- > > > > From: "Erik Sundberg" < ESundberg at nitelusa.com > > > > > To: nanog at nanog.org > > > > Sent: Wednesday, October 8, 2014 9:18:16 PM > > > > Subject: IPv6 Default Allocation - What size allocation are you giving > > > out > > > > > > > > I am planning out our IPv6 deployment right now and I am trying to figure > > > out > > > > our default allocation for customer LAN blocks. So what is everyone > > > giving > > > > for a default LAN allocation for IPv6 Customers. I guess the idea of > > > > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > > > > cringe at the waste. Especially when you know 90% of customers will never > > > > have more than 2 or 3 subnets. As I see it the customer can always ask > > > for > > > > more IPv6 Space. > > > > > > > > /64 > > > > /60 > > > > /56 > > > > /48 > > > > > > > > Small Customer? > > > > Medium Customer? > > > > Large Customer? > > > > > > > > Thanks > > > > > > > > Erik > > > > > > > > ________________________________ > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > > > files > > > or > > > > previous e-mail messages attached to it may contain confidential > > > information > > > > that is legally privileged. If you are not the intended recipient, or a > > > > person responsible for delivering it to the intended recipient, you are > > > > hereby notified that any disclosure, copying, distribution or use of any > > > of > > > > the information contained in or attached to this transmission is STRICTLY > > > > PROHIBITED. If you have received this transmission in error please notify > > > > the sender immediately by replying to this e-mail. You must destroy the > > > > original transmission and its attachments without reading or saving in > > > any > > > > manner. Thank you. > > > > > From faisal at snappytelecom.net Thu Oct 9 04:14:57 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:14:57 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> Message-ID: <1469958135.131720.1412828097856.JavaMail.zimbra@snappytelecom.net> Fair point.... just as a follow up question... is giving a /64 to a Residential Customer not a good idea, because it would not allow them to have additional routed segments ? (since Best Practices is to use a /64 on each link as link connectivity address) or is there some other reasoning that I am failing to see/ understand ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Philip Dorr" > Cc: nanog at nanog.org > Sent: Wednesday, October 8, 2014 11:54:36 PM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > You should probably increase those allocations. > > Residential & Small Business Customers: /56 > > Medium & Large size Business Customers: /48 > > Multi-location Business Customer: /48 per site > > On Wed, Oct 8, 2014 at 10:37 PM, Faisal Imtiaz > wrote: > > We are going thru a similar process.. from all of my reading, best practice > > discussions etc.. > > > > Here is what i have understood so far:- > > > > Residential Customers: /64 > > > > Small & Medium size Business Customers: /56 > > > > Large Business size or a multi-location Business Customer: /48 > > > > Don't skimp on allocating the subnets like we do on IPv4 > > Better to be 'wasteful' than have to come back to re-number or re-allocate > > . > > > > Regards > > > > > > Faisal Imtiaz > > Snappy Internet & Telecom > From royce at techsolvency.com Thu Oct 9 04:14:51 2014 From: royce at techsolvency.com (Royce Williams) Date: Wed, 8 Oct 2014 20:14:51 -0800 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: On Wed, Oct 8, 2014 at 8:07 PM, Faisal Imtiaz wrote: > Like I said, this was my understanding.... I am glad that it is being > pointed out to be in-correct.... > > I don't have a reason for why a /64 as much as I also don't have any > reason Why NOT.... > > So, let me ask the question in a different manner... > What is the wisdom / reasoning behind needing to give a /56 to a > Residential customer (vs a /64). > Quoting RFC6177 (successor to RFC3177): While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either. A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.) The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56. Royce From kennethfinnegan2007 at gmail.com Thu Oct 9 04:16:59 2014 From: kennethfinnegan2007 at gmail.com (Kenneth Finnegan) Date: Wed, 8 Oct 2014 21:16:59 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: > What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). What happens when the resident pulls their car into their garage and their car requests a unique /64 so the various computers on the CAN can start syncing with the Internet? Car's media center starts downloading new music, engine controller uploads diagnostics, GPS navigator starts downloading new maps, etc. Different example: people like Jim Gettys and Dave Taht are pushing for consumer routers to start routing between WiFi and Ethernet instead of bridging the two out of the box, since WiFi tends to fall over so hard on multicast/broadcast traffic. Suddenly their router needs two subnets, and either one of them doesn't work, or they have to live with reduced WiFi performance. -- Kenneth Finnegan http://blog.thelifeofkenneth.com/ From faisal at snappytelecom.net Thu Oct 9 04:18:03 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:18:03 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: <1929349340.131740.1412828283553.JavaMail.zimbra@snappytelecom.net> Awesome, Thank you Royce, the missing piece has clicked in place... :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Royce Williams" > To: "Faisal Imtiaz" > Cc: "Sam Silvester" , "NANOG" > Sent: Thursday, October 9, 2014 12:14:51 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving > out > On Wed, Oct 8, 2014 at 8:07 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: > > Like I said, this was my understanding.... I am glad that it is being > > pointed > > out to be in-correct.... > > > I don't have a reason for why a /64 as much as I also don't have any reason > > Why NOT.... > > > So, let me ask the question in a different manner... > > > What is the wisdom / reasoning behind needing to give a /56 to a > > Residential > > customer (vs a /64). > > Quoting RFC6177 (successor to RFC3177): > While the /48 recommendation does simplify address space management > for end sites, it has also been widely criticized as being wasteful. > For example, a large business (which may have thousands of employees) > would, by default, receive the same amount of address space as a home > user, who today typically has a single (or small number of) LAN and a > small number of devices (dozens or less). While it seems likely that > the size of a typical home network will grow over the next few > decades, it is hard to argue that home sites will make use of 65K > subnets within the foreseeable future. At the same time, it might be > tempting to give home sites a single /64, since that is already > significantly more address space compared with today's IPv4 practice. > However, this precludes the expectation that even home sites will > grow to support multiple subnets going forward. Hence, it is > strongly intended that even home sites be given multiple subnets > worth of space, by default. Hence, this document still recommends > giving home sites significantly more than a single /64, but does not > recommend that every home site be given a /48 either. > A change in policy (such as above) would have a significant impact on > address consumption projections and the expected longevity for IPv6. > For example, changing the default assignment from a /48 to /56 (for > the vast majority of end sites, e.g., home sites) would result in a > savings of up to 8 bits, reducing the "total projected address > consumption" by (up to) 8 bits or two orders of magnitude. (The > exact amount of savings depends on the relative number of home users > compared with the number of larger sites.) > The above-mentioned goals of RFC 3177 can easily be met by giving > home users a default assignment of less than /48, such as a /56. > Royce From faisal at snappytelecom.net Thu Oct 9 04:21:44 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:21:44 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: <563506829.131768.1412828504673.JavaMail.zimbra@snappytelecom.net> Yep, understood....... in the ipv6 world we are looking at needing a significantly more 'routing' connectivity, than we do in the current ipv4 world. Thank you. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Kenneth Finnegan" > To: "Faisal Imtiaz" , nanog at nanog.org > Sent: Thursday, October 9, 2014 12:16:59 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > > What is the wisdom / reasoning behind needing to give a /56 to a > > Residential customer (vs a /64). > > What happens when the resident pulls their car into their garage and > their car requests a unique /64 so the various computers on the CAN > can start syncing with the Internet? Car's media center starts > downloading new music, engine controller uploads diagnostics, GPS > navigator starts downloading new maps, etc. > > Different example: people like Jim Gettys and Dave Taht are pushing > for consumer routers to start routing between WiFi and Ethernet > instead of bridging the two out of the box, since WiFi tends to fall > over so hard on multicast/broadcast traffic. Suddenly their router > needs two subnets, and either one of them doesn't work, or they have > to live with reduced WiFi performance. > -- > Kenneth Finnegan > http://blog.thelifeofkenneth.com/ > From tagno25 at gmail.com Thu Oct 9 04:21:54 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Wed, 8 Oct 2014 23:21:54 -0500 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1469958135.131720.1412828097856.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1469958135.131720.1412828097856.JavaMail.zimbra@snappytelecom.net> Message-ID: The biggest issue I see with only giving a /64 is that many residential customers may have have two routers, if the modem is not bridged and does not have WiFi. Another issue would be for people who want to use the guest SSID of many routers. With IPv6 I could see each SSID getting a /64. From faisal at snappytelecom.net Thu Oct 9 04:24:17 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:24:17 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1469958135.131720.1412828097856.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1469958135.131720.1412828097856.JavaMail.zimbra@snappytelecom.net> Message-ID: <190897016.131772.1412828657896.JavaMail.zimbra@snappytelecom.net> haha.. email timing delay ...... The follow up question has been answered by a few others there, in their previous emails with appropriate explanations. Thank you to everyone who responded. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Faisal Imtiaz" > To: tagno25 at gmail.com > Cc: nanog at nanog.org > Sent: Thursday, October 9, 2014 12:14:57 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > > Fair point.... > > just as a follow up question... is giving a /64 to a Residential Customer not > a good idea, because it would not allow them to have additional routed > segments ? (since Best Practices is to use a /64 on each link as link > connectivity address) or is there some other reasoning that I am failing to > see/ understand ? > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Philip Dorr" > > Cc: nanog at nanog.org > > Sent: Wednesday, October 8, 2014 11:54:36 PM > > Subject: Re: IPv6 Default Allocation - What size allocation are you giving > > out > > > > You should probably increase those allocations. > > > > Residential & Small Business Customers: /56 > > > > Medium & Large size Business Customers: /48 > > > > Multi-location Business Customer: /48 per site > > > > On Wed, Oct 8, 2014 at 10:37 PM, Faisal Imtiaz > > wrote: > > > We are going thru a similar process.. from all of my reading, best > > > practice > > > discussions etc.. > > > > > > Here is what i have understood so far:- > > > > > > Residential Customers: /64 > > > > > > Small & Medium size Business Customers: /56 > > > > > > Large Business size or a multi-location Business Customer: /48 > > > > > > Don't skimp on allocating the subnets like we do on IPv4 > > > Better to be 'wasteful' than have to come back to re-number or > > > re-allocate > > > . > > > > > > Regards > > > > > > > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > > From marka at isc.org Thu Oct 9 04:25:28 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 15:25:28 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 04:07:09 -0000." <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141009042528.7B65C212DE0A@rock.dv.isc.org> In message <1627782497.131675.1412827629110.JavaMail.zimbra at snappytelecom.net>, Faisal Imtiaz writes: > Like I said, this was my understanding.... I am glad that it is being pointed > out to be in-correct.... > > I don't have a reason for why a /64 as much as I also don't have any reason W > hy NOT.... Because /64 only allows for a single subnet running SLAAC with currently defined specifications. > So, let me ask the question in a different manner... > What is the wisdom / reasoning behind needing to give a /56 to a Residential > customer (vs a /64). A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary. There is plenty of address space even handing out /48's to everyone. Only short sighted ISP's hand out /56's to residential customers. > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > ----- Original Message ----- > > > From: "Sam Silvester" > > To: "Faisal Imtiaz" > > Cc: "Erik Sundberg" , "NANOG" > > Sent: Wednesday, October 8, 2014 11:47:01 PM > > Subject: Re: IPv6 Default Allocation - What size allocation are you giving > > out > > > Why would you only allocate a residential customer a single /64? > > > That's totally short sighted in my view. > > > On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal at snappytelecom.net > > > wrote: > > > > We are going thru a similar process.. from all of my reading, best practi > ce > > > discussions etc.. > > > > > > Here is what i have understood so far:- > > > > > > Residential Customers: /64 > > > > > > Small & Medium size Business Customers: /56 > > > > > > Large Business size or a multi-location Business Customer: /48 > > > > > > Don't skimp on allocating the subnets like we do on IPv4 > > > > > Better to be 'wasteful' than have to come back to re-number or re-allocat > e > > > . > > > > > > Regards > > > > > > Faisal Imtiaz > > > > > Snappy Internet & Telecom > > > > > > ----- Original Message ----- > > > > > > From: "Erik Sundberg" < ESundberg at nitelusa.com > > > > > > > To: nanog at nanog.org > > > > > > Sent: Wednesday, October 8, 2014 9:18:16 PM > > > > > > Subject: IPv6 Default Allocation - What size allocation are you giving > > > > out > > > > > > > > > > > > I am planning out our IPv6 deployment right now and I am trying to figu > re > > > > out > > > > > > our default allocation for customer LAN blocks. So what is everyone > > > > giving > > > > > > for a default LAN allocation for IPv6 Customers. I guess the idea of > > > > > > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > > > > > > cringe at the waste. Especially when you know 90% of customers will nev > er > > > > > > have more than 2 or 3 subnets. As I see it the customer can always ask > > > > for > > > > > > more IPv6 Space. > > > > > > > > > > > > /64 > > > > > > /60 > > > > > > /56 > > > > > > /48 > > > > > > > > > > > > Small Customer? > > > > > > Medium Customer? > > > > > > Large Customer? > > > > > > > > > > > > Thanks > > > > > > > > > > > > Erik > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > > > > files > > > > or > > > > > > previous e-mail messages attached to it may contain confidential > > > > information > > > > > > that is legally privileged. If you are not the intended recipient, or a > > > > > > person responsible for delivering it to the intended recipient, you are > > > > > > hereby notified that any disclosure, copying, distribution or use of an > y > > > > of > > > > > > the information contained in or attached to this transmission is STRICT > LY > > > > > > PROHIBITED. If you have received this transmission in error please noti > fy > > > > > > the sender immediately by replying to this e-mail. You must destroy the > > > > > > original transmission and its attachments without reading or saving in > > > > any > > > > > > manner. Thank you. > > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From faisal at snappytelecom.net Thu Oct 9 04:32:39 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:32:39 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009042528.7B65C212DE0A@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> Message-ID: <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > zone delegated on a nibble boundary. Understood... > There is plenty of address space even handing out /48's to everyone. Also Understood. >Only short sighted ISP's hand out /56's to residential customers. I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Mark Andrews" > To: "Faisal Imtiaz" > Cc: "Sam Silvester" , "NANOG" > Sent: Thursday, October 9, 2014 12:25:28 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > > In message > <1627782497.131675.1412827629110.JavaMail.zimbra at snappytelecom.net>, > Faisal Imtiaz writes: > > Like I said, this was my understanding.... I am glad that it is being > > pointed > > out to be in-correct.... > > > > I don't have a reason for why a /64 as much as I also don't have any reason > > W > > hy NOT.... > > Because /64 only allows for a single subnet running SLAAC with > currently defined specifications. > > > So, let me ask the question in a different manner... > > What is the wisdom / reasoning behind needing to give a /56 to a > > Residential > > customer (vs a /64). > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > zone delegated on a nibble boundary. There is plenty of address > space even handing out /48's to everyone. Only short sighted ISP's > hand out /56's to residential customers. > > > Regards. > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > ----- Original Message ----- > > > > > From: "Sam Silvester" > > > To: "Faisal Imtiaz" > > > Cc: "Erik Sundberg" , "NANOG" > > > Sent: Wednesday, October 8, 2014 11:47:01 PM > > > Subject: Re: IPv6 Default Allocation - What size allocation are you > > > giving > > > out > > > > > Why would you only allocate a residential customer a single /64? > > > > > That's totally short sighted in my view. > > > > > On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal at snappytelecom.net > > > > > > > wrote: > > > > > > We are going thru a similar process.. from all of my reading, best > > > > practi > > ce > > > > discussions etc.. > > > > > > > > > Here is what i have understood so far:- > > > > > > > > > Residential Customers: /64 > > > > > > > > > Small & Medium size Business Customers: /56 > > > > > > > > > Large Business size or a multi-location Business Customer: /48 > > > > > > > > > Don't skimp on allocating the subnets like we do on IPv4 > > > > > > > Better to be 'wasteful' than have to come back to re-number or > > > > re-allocat > > e > > > > . > > > > > > > > > Regards > > > > > > > > > Faisal Imtiaz > > > > > > > Snappy Internet & Telecom > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Erik Sundberg" < ESundberg at nitelusa.com > > > > > > > > > To: nanog at nanog.org > > > > > > > > Sent: Wednesday, October 8, 2014 9:18:16 PM > > > > > > > > Subject: IPv6 Default Allocation - What size allocation are you > > > > > giving > > > > > out > > > > > > > > > > > > > > > > I am planning out our IPv6 deployment right now and I am trying to > > > > > figu > > re > > > > > out > > > > > > > > our default allocation for customer LAN blocks. So what is everyone > > > > > giving > > > > > > > > for a default LAN allocation for IPv6 Customers. I guess the idea of > > > > > > > > handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes > > > > > me > > > > > > > > cringe at the waste. Especially when you know 90% of customers will > > > > > nev > > er > > > > > > > > have more than 2 or 3 subnets. As I see it the customer can always > > > > > ask > > > > > for > > > > > > > > more IPv6 Space. > > > > > > > > > > > > > > > > /64 > > > > > > > > /60 > > > > > > > > /56 > > > > > > > > /48 > > > > > > > > > > > > > > > > Small Customer? > > > > > > > > Medium Customer? > > > > > > > > Large Customer? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Erik > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > > > > > files > > > > > or > > > > > > > > previous e-mail messages attached to it may contain confidential > > > > > information > > > > > > > > that is legally privileged. If you are not the intended recipient, or > > > > > a > > > > > > > > person responsible for delivering it to the intended recipient, you > > > > > are > > > > > > > > hereby notified that any disclosure, copying, distribution or use of > > > > > an > > y > > > > > of > > > > > > > > the information contained in or attached to this transmission is > > > > > STRICT > > LY > > > > > > > > PROHIBITED. If you have received this transmission in error please > > > > > noti > > fy > > > > > > > > the sender immediately by replying to this e-mail. You must destroy > > > > > the > > > > > > > > original transmission and its attachments without reading or saving > > > > > in > > > > > any > > > > > > > > manner. Thank you. > > > > > > > > > > > > -- > 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 Thu Oct 9 04:40:07 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 15:40:07 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 04:32:39 -0000." <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141009044007.A75E6212E0D1@rock.dv.isc.org> In message <482678376.131852.1412829159356.JavaMail.zimbra at snappytelecom.net>, Faisal Imtiaz writes: > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > > zone delegated on a nibble boundary. > > Understood... > > > There is plenty of address space even handing out /48's to everyone. > > Also Understood. > > >Only short sighted ISP's hand out /56's to residential customers. > > I am curious as to why you say it is short sighted? what is the technical or > otherwise any other reasoning for such statement ? 256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource. Mark > Faisal Imtiaz > Snappy Internet & Telecom -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From faisal at snappytelecom.net Thu Oct 9 04:45:18 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 04:45:18 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009044007.A75E6212E0D1@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> Message-ID: <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> ====================================== > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the technical > > or > > otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what >developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a >scares resource. ======================================= So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Mark Andrews" > To: "Faisal Imtiaz" > Cc: "Sam Silvester" , "NANOG" > Sent: Thursday, October 9, 2014 12:40:07 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > > In message > <482678376.131852.1412829159356.JavaMail.zimbra at snappytelecom.net>, > Faisal Imtiaz writes: > > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > > > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > > > zone delegated on a nibble boundary. > > > > Understood... > > > > > There is plenty of address space even handing out /48's to everyone. > > > > Also Understood. > > > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the technical > > or > > otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number > of subnets residences get you restrict what developers will design > for. Subnets don't need to be scares resource. ISP's that default to > /56 are making them a scares resource. > > Mark > > > Faisal Imtiaz > > Snappy Internet & Telecom > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From drc at virtualized.org Thu Oct 9 04:55:22 2014 From: drc at virtualized.org (David Conrad) Date: Wed, 8 Oct 2014 21:55:22 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> Message-ID: <26DD5674-733B-4650-8B86-62E6DD3FC5E9@virtualized.org> Faisal, On Oct 8, 2014, at 9:45 PM, Faisal Imtiaz wrote: > So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? The technical reasoning behind /48 has been documented in many places. Lots of folks, particularly those who’ve struggled with justifying their “need” for IPv4 have developed “‘opinion’ / ‘feel’” about conserving address space. If you remove the limitations of IPv4 in terms of quantity of address space, what are the compelling technical reasons for longer than /48? Regards, -drc From rocca at start.ca Thu Oct 9 04:59:14 2014 From: rocca at start.ca (Peter Rocca) Date: Thu, 9 Oct 2014 04:59:14 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> Message-ID: To paraphrase a post on this list a while ago (my apologies for lack of reference). There are two kinds of waste: - the first kind of waste is providing 'too many' subnets for someone; - the second kind of waste is leaving the space unallocated forever. If we choose the first option and somehow burn through the 35 trillion /48's out of the first /3 we're drawing from (ie, almost 5000 /48's for every person on the planet) then we can always reconsider how to be more conservative with the remaining 88% of unallocated IPv6 space. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: October-09-14 12:45 AM To: Mark Andrews Cc: NANOG Subject: Re: IPv6 Default Allocation - What size allocation are you giving out ====================================== > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the > > technical or otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what >developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a >scares resource. ======================================= So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Mark Andrews" > To: "Faisal Imtiaz" > Cc: "Sam Silvester" , "NANOG" > > Sent: Thursday, October 9, 2014 12:40:07 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you > giving out > > > In message > <482678376.131852.1412829159356.JavaMail.zimbra at snappytelecom.net>, > Faisal Imtiaz writes: > > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > > > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > > > zone delegated on a nibble boundary. > > > > Understood... > > > > > There is plenty of address space even handing out /48's to everyone. > > > > Also Understood. > > > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the > > technical or otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number of > subnets residences get you restrict what developers will design for. > Subnets don't need to be scares resource. ISP's that default to > /56 are making them a scares resource. > > Mark > > > Faisal Imtiaz > > Snappy Internet & Telecom > -- > 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 Oct 9 05:01:58 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 08 Oct 2014 22:01:58 -0700 Subject: RADB In-Reply-To: <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> Message-ID: <543616C6.8000100@bogus.com> On 10/8/14 7:35 PM, Brandon Wade wrote: > > >>> For a newbie, how does one go about learning the basic's of IRRd. > > That pretty much sums it up. I feel like I'm stuck reading RFC's that are too overly complex for something that seems like it shouldn't be complex. Anyone know of a > quick 101 intro to routing registries with a simple example of an AS > that has two upstream providers and a handful of peers and downstream > AS's? There's a decentish tutorial from nanog 51 https://www.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf ripe's training materials are here: http://www.ripe.net/lir-services/training/material/ripe-ncc-training-material#RR I'd start with the nanog tutorial, I'd treat it as background till you get to the end, and the look at it again with an eye towards what you need to do which is probably create a few route objects and an aut-num. > Brandon > > > On Wednesday, October 8, 2014 8:15 PM, Faisal Imtiaz wrote: > > > > I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd.. > > So the real question Brandon is asking.. > > For a newbie, how does one go about learning the basic's of IRRd. > > Speaking for myself, if there is a good answer, I would welcome it. > > Here is what I had to do... > > 1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource. > > 2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc. > > 3. Did Google searches on finding some of the older NANOG presentations about IRRd. > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > > > ----- Original Message ----- >> From: "Brandon Wade" >> To: nanog at nanog.org >> Sent: Wednesday, October 8, 2014 4:44:07 PM >> Subject: RADB >> >> Hi, >> >> I really don't know where else to post this. I recently subscribed to RADB >> and added route objects and route6 objects for our prefixes we announce. Of >> course an aut-num object was created and I created a list of ASN's that are >> downstream customers in an as-set list. But, since this is my first time >> ever subscribing to a routing registry, I really don't know for sure that >> I'm doing everything correctly. So, I submitted an e-mail to RADB and >> requested that they review what I've done and to see if I'm doing it >> correctly. Well, the reply I received was far less than I could have ever >> imagined: >> >> "RADb is a self-serve service. If you have specific questions, we can >> address those. However, the type of audit requested is not a part of the >> standard offering associated with this service." >> >> So my question is, how am I supposed to verify that what I've done is what is >> supposed to be done and that I am doing this correctly? >> >> My next question is, why would RADB offer zero support for confirming this? >> And lastly, why should my organization pay $500 per year to a service that >> is unwilling to assist in making sure their subscriber is using their >> service properly? >> >> Best regards, >> Brandon Wade >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From cgucker at onesc.net Thu Oct 9 05:02:09 2014 From: cgucker at onesc.net (Charles Gucker) Date: Thu, 9 Oct 2014 01:02:09 -0400 Subject: RADB In-Reply-To: <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> Message-ID: Take a look: https://www.arin.net/resources/routing/ charles On Wed, Oct 8, 2014 at 10:35 PM, Brandon Wade wrote: > > >>> For a newbie, how does one go about learning the basic's of IRRd. > > That pretty much sums it up. I feel like I'm stuck reading RFC's that are too overly complex for something that seems like it shouldn't be complex. Anyone know of a > quick 101 intro to routing registries with a simple example of an AS > that has two upstream providers and a handful of peers and downstream > AS's? > > Brandon > > > On Wednesday, October 8, 2014 8:15 PM, Faisal Imtiaz wrote: > > > > I can relate to this, having gone thru a similar process/experience fairly recently in using IRRd.. > > So the real question Brandon is asking.. > > For a newbie, how does one go about learning the basic's of IRRd. > > Speaking for myself, if there is a good answer, I would welcome it. > > Here is what I had to do... > > 1. Used Radb lookup on different AS-Set and ASN to get a feel on how others were using this resource. > > 2. Went thru the ARIN IRRd Tutorial / info pages on how to create records etc. > > 3. Did Google searches on finding some of the older NANOG presentations about IRRd. > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > > > ----- Original Message ----- >> From: "Brandon Wade" >> To: nanog at nanog.org >> Sent: Wednesday, October 8, 2014 4:44:07 PM >> Subject: RADB >> >> Hi, >> >> I really don't know where else to post this. I recently subscribed to RADB >> and added route objects and route6 objects for our prefixes we announce. Of >> course an aut-num object was created and I created a list of ASN's that are >> downstream customers in an as-set list. But, since this is my first time >> ever subscribing to a routing registry, I really don't know for sure that >> I'm doing everything correctly. So, I submitted an e-mail to RADB and >> requested that they review what I've done and to see if I'm doing it >> correctly. Well, the reply I received was far less than I could have ever >> imagined: >> >> "RADb is a self-serve service. If you have specific questions, we can >> address those. However, the type of audit requested is not a part of the >> standard offering associated with this service." >> >> So my question is, how am I supposed to verify that what I've done is what is >> supposed to be done and that I am doing this correctly? >> >> My next question is, why would RADB offer zero support for confirming this? >> And lastly, why should my organization pay $500 per year to a service that >> is unwilling to assist in making sure their subscriber is using their >> service properly? >> >> Best regards, >> Brandon Wade >> From marka at isc.org Thu Oct 9 05:02:37 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 16:02:37 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 04:45:18 -0000." <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141009050237.2C177212E3C0@rock.dv.isc.org> In message <2083423091.131955.1412829918586.JavaMail.zimbra at snappytelecom.net>, Faisal Imtiaz writes: > ====================================== > > > >Only short sighted ISP's hand out /56's to residential customers. > > > > > > I am curious as to why you say it is short sighted? what is the technical > > > or > > > otherwise any other reasoning for such statement ? > > > > 256 is *not* a big number of subnets. By restricting the number of subnets > residences get you restrict what >developers will design for. Subnets don't > need to be scares resource. ISP's that default to /56 are making them a >sc > ares resource. > ======================================= > > So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and > not something which has a (presently) compelling technical reasoning behind i > t ? There are thousands of examples of things being designed for the lowest common denominator. There are thousand of examples of "this will never be reached" only to have the thing be reached. Every time this happens it becomes expensive to correct. It causes operational issues for those on the leading edge. Your home router should support thousands of internal routes and be able to hand out thousands of prefixes all in a $50 box. Memory is cheap. It doesn't require lots of cpu to support something like a house even with thousands of subnets. If /56 becomes the norm the boxes will end up being designed for 256 subnets rather than the thousands it should be designed for thousands the hardware is capable of supporting. This unfortunately is human nature. > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Mark Andrews" > > To: "Faisal Imtiaz" > > Cc: "Sam Silvester" , "NANOG" > > Sent: Thursday, October 9, 2014 12:40:07 AM > > Subject: Re: IPv6 Default Allocation - What size allocation are you giving > out > > > > > > In message > > <482678376.131852.1412829159356.JavaMail.zimbra at snappytelecom.net>, > > Faisal Imtiaz writes: > > > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > > > > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > > > > zone delegated on a nibble boundary. > > > > > > Understood... > > > > > > > There is plenty of address space even handing out /48's to everyone. > > > > > > Also Understood. > > > > > > >Only short sighted ISP's hand out /56's to residential customers. > > > > > > I am curious as to why you say it is short sighted? what is the technical > > > or > > > otherwise any other reasoning for such statement ? > > > > 256 is *not* a big number of subnets. By restricting the number > > of subnets residences get you restrict what developers will design > > for. Subnets don't need to be scares resource. ISP's that default to > > /56 are making them a scares resource. > > > > Mark > > > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > -- > > 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 hugo at slabnet.com Thu Oct 9 05:06:23 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 8 Oct 2014 22:06:23 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009044007.A75E6212E0D1@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> Message-ID: <20141009050623.GB15355@bamboo.slabnet.com> Mark, >> >Only short sighted ISP's hand out /56's to residential customers. >> >> I am curious as to why you say it is short sighted? what is the technical or >> otherwise any other reasoning for such statement ? > >256 is *not* a big number of subnets. By restricting the number >of subnets residences get you restrict what developers will design >for. Subnets don't need to be scares resource. ISP's that default to >/56 are making them a scares resource. The excerpt Royce quoted from RFC6177 (requoted below) seems to back away from /48s by default to all resi users and land in a somewhat vague "more than a /64 please, but we're not specifically recommending /48s across the board for residential" before specifically mentioning /56 assignments. The general push in the community is towards /48 across the board. Any comments on why the RFC backs away from that? Is this just throwing a bone to the masses complaining about "waste"? btw: hat tip to Peter Rocca for a kind of scale we're talking about for allocatable space. -- Hugo >Quoting RFC6177 (successor to RFC3177): > > While the /48 recommendation does simplify address space management > for end sites, it has also been widely criticized as being wasteful. > For example, a large business (which may have thousands of employees) > would, by default, receive the same amount of address space as a home > user, who today typically has a single (or small number of) LAN and a > small number of devices (dozens or less). While it seems likely that > the size of a typical home network will grow over the next few > decades, it is hard to argue that home sites will make use of 65K > subnets within the foreseeable future. At the same time, it might be > tempting to give home sites a single /64, since that is already > significantly more address space compared with today's IPv4 practice. > However, this precludes the expectation that even home sites will > grow to support multiple subnets going forward. Hence, it is > strongly intended that even home sites be given multiple subnets > worth of space, by default. Hence, this document still recommends > giving home sites significantly more than a single /64, but does not > recommend that every home site be given a /48 either. > > A change in policy (such as above) would have a significant impact on > address consumption projections and the expected longevity for IPv6. > For example, changing the default assignment from a /48 to /56 (for > the vast majority of end sites, e.g., home sites) would result in a > savings of up to 8 bits, reducing the "total projected address > consumption" by (up to) 8 bits or two orders of magnitude. (The > exact amount of savings depends on the relative number of home users > compared with the number of larger sites.) > > The above-mentioned goals of RFC 3177 can easily be met by giving > home users a default assignment of less than /48, such as a /56. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From gary.buhrmaster at gmail.com Thu Oct 9 05:06:24 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 9 Oct 2014 05:06:24 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> Message-ID: On Thu, Oct 9, 2014 at 4:45 AM, Faisal Imtiaz wrote: .... > So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Think of something like HIPnet https://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00 http://www.cablelabs.com/the-future-of-home-networking-putting-the-hip-in-hipnet/ with multiple levels of home devices performing routing (prefix delegation), with multiple networks off of each. Even a /56 can easily end up being too little for multiple levels in a residence. If one believes in the IoT/IoE hype, everything will have a IPv6 address, and many of those devices might have multiple internal networks. So, yes, I assert based on a "feel" that a /48 is the right choice, because I am hoping to not make the same mistakes as with IPv4, and under estimate the growth of the network by the customers, resulting in all sorts of convoluted workarounds for not having enough addresses and options to do things right. From j at arpa.com Thu Oct 9 05:09:59 2014 From: j at arpa.com (jamie rishaw) Date: Thu, 9 Oct 2014 00:09:59 -0500 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: This makes no sense. I have two /48s routed to my house. ..to my house. The idea that anyone is giving anything less than a 64 is unreasonable and will lead to an exponential growth in routing tables.. it's asinine and very short sighted. Sure, back in the day, I had a server, a couple desktops and a BRI and wow who would need more than an ipv4 /28--but let's face reality here--every thing, every switch, every night bulb, every door, every window, every skylight, every temperature sensor, every tv, every device that a friend brings over or even any device that I allow public access to.. every cat, every dog, every hamster is going to be microchipped and every single unit is going to need to be accessible.... Hell, I have two ips/one each for each of my two cat boxes that tell me current status, c'mon. My TiVos, my game consoles, my cable boxes, my two printers.. all have their own address. To think in an unframed context that you know what everyone everywhere will need is nothing short of naive and is everything elementarily assumptive of (ahem) The Internet of Things. The examples I gave are just for my house.. now multiply that times a small, medium, large, xl, enterprise or global entity and do the math These arguments and debates make me sad. I suppose it's my own fault for assuming that everyone in this ML is a forward thinker. -j On Wed, Oct 8, 2014 at 8:18 PM, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure > out our default allocation for customer LAN blocks. So what is everyone > giving for a default LAN allocation for IPv6 Customers. I guess the idea > of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > cringe at the waste. Especially when you know 90% of customers will never > have more than 2 or 3 subnets. As I see it the customer can always ask for > more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > -- jamie rishaw // .com.arpa at j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai From j at arpa.com Thu Oct 9 05:16:30 2014 From: j at arpa.com (jamie rishaw) Date: Thu, 9 Oct 2014 00:16:30 -0500 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: (PS If I wake up in the morning and find out that someone has hacked my CatGenie litter boxes, I will hunt you down). "NANOG: From Cat Poo to IPv6, We've Got It Covered" On Thu, Oct 9, 2014 at 12:09 AM, jamie rishaw wrote: > This makes no sense. > > I have two /48s routed to my house. > > ..to my house. > > The idea that anyone is giving anything less than a 64 is unreasonable and > will lead to an exponential growth in routing tables.. it's asinine and > very short sighted. > > Sure, back in the day, I had a server, a couple desktops and a BRI and wow > who would need more than an ipv4 /28--but let's face reality here--every > thing, every switch, every night bulb, every door, every window, every > skylight, every temperature sensor, every tv, every device that a friend > brings over or even any device that I allow public access to.. every cat, > every dog, every hamster is going to be microchipped and every single unit > is going to need to be accessible.... Hell, I have two ips/one each for > each of my two cat boxes that tell me current status, c'mon. > > My TiVos, my game consoles, my cable boxes, my two printers.. all have > their own address. > > To think in an unframed context that you know what everyone everywhere > will need is nothing short of naive and is everything elementarily > assumptive of (ahem) The Internet of Things. > > The examples I gave are just for my house.. now multiply that times a > small, medium, large, xl, enterprise or global entity and do the math > > These arguments and debates make me sad. I suppose it's my own fault for > assuming that everyone in this ML is a forward thinker. > -j > > On Wed, Oct 8, 2014 at 8:18 PM, Erik Sundberg > wrote: > >> I am planning out our IPv6 deployment right now and I am trying to figure >> out our default allocation for customer LAN blocks. So what is everyone >> giving for a default LAN allocation for IPv6 Customers. I guess the idea >> of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me >> cringe at the waste. Especially when you know 90% of customers will never >> have more than 2 or 3 subnets. As I see it the customer can always ask for >> more IPv6 Space. >> >> /64 >> /60 >> /56 >> /48 >> >> Small Customer? >> Medium Customer? >> Large Customer? >> >> Thanks >> >> Erik >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, >> files or previous e-mail messages attached to it may contain confidential >> information that is legally privileged. If you are not the intended >> recipient, or a person responsible for delivering it to the intended >> recipient, you are hereby notified that any disclosure, copying, >> distribution or use of any of the information contained in or attached to >> this transmission is STRICTLY PROHIBITED. If you have received this >> transmission in error please notify the sender immediately by replying to >> this e-mail. You must destroy the original transmission and its attachments >> without reading or saving in any manner. Thank you. >> > > > > -- > jamie rishaw // .com.arpa at j <- reverse it. ish. > > "...let's consider this world like a family and care about each other..." > -Malala Yousafzai > -- jamie rishaw // .com.arpa at j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai From gary.buhrmaster at gmail.com Thu Oct 9 05:26:17 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 9 Oct 2014 05:26:17 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: On Thu, Oct 9, 2014 at 5:16 AM, jamie rishaw wrote: > (PS If I wake up in the morning and find out that someone has hacked my > CatGenie litter boxes, I will hunt you down). I am sure any hacking will result in taking a dump. From gary.buhrmaster at gmail.com Thu Oct 9 05:28:54 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 9 Oct 2014 05:28:54 +0000 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: On Thu, Oct 9, 2014 at 5:09 AM, jamie rishaw wrote: ..... > These arguments and debates make me sad. I suppose it's my own fault for > assuming that everyone in this ML is a forward thinker. Get used to disappointment. From swmike at swm.pp.se Thu Oct 9 05:34:34 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Oct 2014 07:34:34 +0200 (CEST) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: On Thu, 9 Oct 2014, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? /56 per residential customer, /48 per corporate customer. If you're doing server hosting or alike, I'd do /56 per customer there as well, even if the first lan is only /64, because after a while you'll find out that they want to run virtual machines and want you to route /64:s to them instead of bridging. You definitely want to do this so you don't have to keep a huge ND table for all those IPs that your customer will be using in the future. I'd set 20 ND entry limit per LAN where you have equipment, and if the customer wants to use more concurrent addresses, then they have to accept that you route the networks to them. This is true for all types of customers. -- Mikael Abrahamsson email: swmike at swm.pp.se From saku at ytti.fi Thu Oct 9 06:54:20 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Oct 2014 09:54:20 +0300 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009042528.7B65C212DE0A@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> Message-ID: <20141009065420.GA26275@pob.ytti.fi> On (2014-10-09 15:25 +1100), Mark Andrews wrote: Hi, > Because /64 only allows for a single subnet running SLAAC with > currently defined specifications. I fully agree that larger than 64 must be allocation, in mobile internet, residental DSL, everywhere. I don't think it will happen, but I think it should and I'm happy to say that I was able to impact the national regulatory authority to include this in their recommendation for how IPv6 should be provided. Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT. However, technically SLAAC is happy with arbitrarily small network, and some kit support this (like Cisco). You're going to have to do DAD anyhow, because uniqueness is not guaranteed. -- ++ytti From bill at herrin.us Thu Oct 9 07:02:09 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 03:02:09 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> Message-ID: On Wed, Oct 8, 2014 at 10:48 PM, James R Cutler wrote: > On Oct 8, 2014, at 9:18 PM, Erik Sundberg wrote: >> I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. >> >> /64 >> /60 >> /56 >> /48 Hi Erik, You're asking the right question and you understand the divisible-by-four rule for prefix delegation, which is good. The answer I recommend is: 1. Nothing smaller than /56 unless you know enough about the situation to be sure /56 is unnecessary. In particular, never provide a /64 to a customer... delegate nothing between /61 and /123, ever. You'll just be making mess that you have to clean up later when it turns out they needed 3 LANs after all. 2. Suggest /56 for residential and /48 for business customers as default, didn't ask for something else sizes. 3. /48 for anyone who makes the effort to ask, including residential customers. 99% won't ask and won't care any time in the foreseeable future. 4. Referral to ARIN for anyone who requests more than a /48. If they have a good reason for needing more than 65,000 LANs that reason is likely good enough to justify a direct ARIN assignment. If they don't have a good reason, the experience will teach them that without needing to get them mad at you. > Selection of a default prefix is easy. Here are the steps. > > 4. Keeping in mind > > 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. > 4.2 Your customers want working Internet connections > 4.3 You want income at a minimum of ongoing expense > > make a sensible business decision. IPv6 is large but not infinite. No need to be conservative, but profligate consumption is equally without merit. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From owen at delong.com Thu Oct 9 07:03:02 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:03:02 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> Message-ID: <523FE79D-2C9F-4C78-B568-0ADB56DC4452@delong.com> On Oct 8, 2014, at 2:11 PM, William Herrin wrote: > On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>> On 10/8/2014 08:47, William Herrin wrote: >>>> BART would not have had an FCC license. They'd have had contracts with >>>> the various phone companies to co-locate equipment and provide wired >>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>> breach of contract, and that only if the cell phone companies decided >>>> their behavior was inconsistent with the SLA.. >>> >>> OK that makes more sense than the private answer I got from Roy. I >>> wondered why the FCC didn't take action if there was a license violation. >> >> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 > >> From the article: "Among the issues on which the F.C.C. is seeking > comment is whether it even has authority over the issue." > > Also: "The BART system owns the wireless transmitters and receivers > that allow for cellphone reception within its network.” I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. > I'm not entirely clear how that works. If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. Owen From owen at delong.com Thu Oct 9 07:06:56 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:06:56 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <5435B9DD.7060906@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0lBy1p00o07cg5T01lBzZ4> <5435B9DD.7060906@cox.net> Message-ID: <834E3FAE-F03A-457D-88AC-47094801B6E1@delong.com> > As I recall, BART does not permit anything on their trains--water, baby bottles, and I thought radios. How do they get the authority to do that? They do not permit eating or drinking. You can carry water, baby bottles, etc. on BART trains. You can carry a radio. You can operate a radio. You are prohibited from operating a radio in a manner that is disruptive to other passengers just as on almost any other form of public transit. If you’ve got headphones/earbuds/whatever and use them in a way that doesn’t subject the people around you to the noise coming out of your electronics, then rock out to your heart’s content. Owen From larrysheldon at cox.net Thu Oct 9 07:16:21 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 02:16:21 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0v6v1p00s1cZc5601v6yGq> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0v6v1p00s1cZc5601v6yGq> Message-ID: <54363645.40507@cox.net> On 10/9/2014 02:03, Owen DeLong wrote: > > On Oct 8, 2014, at 2:11 PM, William Herrin wrote: > >> On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >>> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>>> On 10/8/2014 08:47, William Herrin wrote: >>>>> BART would not have had an FCC license. They'd have had contracts with >>>>> the various phone companies to co-locate equipment and provide wired >>>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>>> breach of contract, and that only if the cell phone companies decided >>>>> their behavior was inconsistent with the SLA.. >>>> >>>> OK that makes more sense than the private answer I got from Roy. I >>>> wondered why the FCC didn't take action if there was a license violation. >>> >>> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 >> >>> From the article: "Among the issues on which the F.C.C. is seeking >> comment is whether it even has authority over the issue." >> >> Also: "The BART system owns the wireless transmitters and receivers >> that allow for cellphone reception within its network.” > > I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. > >> I'm not entirely clear how that works. > > If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From owen at delong.com Thu Oct 9 07:15:46 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:15:46 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> Stop cringing and give them /48s. It’s really not going to harm anything. Really. Look at the math. That scale of waste is a very very pale glimmer compared to the LAN side of things where you have 18,000,000,000,000,000,000 (and then some) addresses left over after you put a few hundred thousand hosts on the segment. Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. Household networks will continue to gain sophistication and with automated topologies developed through more advanced applications of DHCP-PD, you will, in fact, start seeing things like WLAN+GuestWLAN+LAN on separate segments, entertainment systems which generate their own segment(s), appliance networks which have separate routed segments, etc. Unfortunately, most of these future applications don’t stand a chance while we’re still mired in IPv4 and IPv4-think about how to allocate addresses. Owen On Oct 8, 2014, at 6:18 PM, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From larrysheldon at cox.net Thu Oct 9 07:20:57 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 02:20:57 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0v8Z1p00i02ea4o01v8bpv> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0lBy1p00o07cg5T01lBzZ4> <5435B9DD.7060906@cox.net> <0v8Z1p00i02ea4o01v8bpv> Message-ID: <54363759.2010709@cox.net> On 10/9/2014 02:06, Owen DeLong wrote: >> As I recall, BART does not permit anything on their trains--water, >> baby bottles, and I thought radios. How do they get the authority >> to do that? > > They do not permit eating or drinking. You can carry water, baby > bottles, etc. on BART trains. > > You can carry a radio. You can operate a radio. You are prohibited > from operating a radio in a manner that is disruptive to other > passengers just as on almost any other form of public transit. > > If you’ve got headphones/earbuds/whatever and use them in a way that > doesn’t subject the people around you to the noise coming out of your > electronics, then rock out to your heart’s content. OK. Not relevant to the discussion then. (I was once told not to drink from what I was carrying. And told I could take a cup of coffee aboard. But the was long ago.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Thu Oct 9 07:21:39 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 02:21:39 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0vH61p01j1cZc5601vH8CK> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0v6v1p00s1cZc5601v6yGq> <0vH61p01j1cZc5601vH8CK> Message-ID: <54363783.8060404@cox.net> On 10/9/2014 02:16, Larry Sheldon wrote: > On 10/9/2014 02:03, Owen DeLong wrote: >> >> On Oct 8, 2014, at 2:11 PM, William Herrin wrote: >> >>> On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >>>> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>>>> On 10/8/2014 08:47, William Herrin wrote: >>>>>> BART would not have had an FCC license. They'd have had contracts >>>>>> with >>>>>> the various phone companies to co-locate equipment and provide wired >>>>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>>>> breach of contract, and that only if the cell phone companies decided >>>>>> their behavior was inconsistent with the SLA.. >>>>> >>>>> OK that makes more sense than the private answer I got from Roy. I >>>>> wondered why the FCC didn't take action if there was a license >>>>> violation. >>>> >>>> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 >>>> >>> >>>> From the article: "Among the issues on which the F.C.C. is seeking >>> comment is whether it even has authority over the issue." >>> >>> Also: "The BART system owns the wireless transmitters and receivers >>> that allow for cellphone reception within its network.” >> >> I’m not sure that statement is accurate. However, there is no >> prohibition against owning a Microcell or other cellular station which >> is operated by a third party under said third party’s license. >> >>> I'm not entirely clear how that works. >> >> If that were truly the case (and I don’t think it is, given BART >> statements that “...the cellular providers are basically tenants and >> are as such subject to…”), I’m pretty sure it would be operated by the >> cellular carrier under their license as a non-owner of the equipment. > > What where the laws and practices in the Olde Days of over-the-air TV > when somebody in a small town installed a translator to repeat > Big-Cities-TV-Station into a small town? > > -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From owen at delong.com Thu Oct 9 07:26:55 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:26:55 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: <2ED07399-34B3-4409-8C6B-A84F6A64F99D@delong.com> I’ll go a step further… If you give a residential customer the /48 that they should be getting, then as DHCP-PD and automatic topologies become more widespread, you have enabled flexibility in the breadth and depth of the bit patterns used to facilitate such hierarchies in the home network environment. If you limit them to 8 bits of subnetting, you are very limited in the constructs (1x8, 2x4, 4x2, or 8x1) which can be achieved. Further, there’s really no advantage to keeping so much extra IPv6 address space on the shelves long past the expiration of the protocol’s useful life. I guarantee you that unless we start doing really stupid things (like using IPv6 /48s as serial numbers for cars), giving /48s to residential customers will not exhaust the current /3 (1/8th of the total IPv6 space) before we hit some other limitation of the protocol. Owen On Oct 8, 2014, at 9:07 PM, Faisal Imtiaz wrote: > Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct.... > > I don't have a reason for why a /64 as much as I also don't have any reason Why NOT.... > > So, let me ask the question in a different manner... > What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > ----- Original Message ----- > >> From: "Sam Silvester" >> To: "Faisal Imtiaz" >> Cc: "Erik Sundberg" , "NANOG" >> Sent: Wednesday, October 8, 2014 11:47:01 PM >> Subject: Re: IPv6 Default Allocation - What size allocation are you giving >> out > >> Why would you only allocate a residential customer a single /64? > >> That's totally short sighted in my view. > >> On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal at snappytelecom.net > >> wrote: > >>> We are going thru a similar process.. from all of my reading, best practice >>> discussions etc.. >> > >>> Here is what i have understood so far:- >> > >>> Residential Customers: /64 >> > >>> Small & Medium size Business Customers: /56 >> > >>> Large Business size or a multi-location Business Customer: /48 >> > >>> Don't skimp on allocating the subnets like we do on IPv4 >> >>> Better to be 'wasteful' than have to come back to re-number or re-allocate >>> . >> > >>> Regards >> > >>> Faisal Imtiaz >> >>> Snappy Internet & Telecom >> > >>> ----- Original Message ----- >> >>>> From: "Erik Sundberg" < ESundberg at nitelusa.com > >> >>>> To: nanog at nanog.org >> >>>> Sent: Wednesday, October 8, 2014 9:18:16 PM >> >>>> Subject: IPv6 Default Allocation - What size allocation are you giving >>>> out >> >>>> >> >>>> I am planning out our IPv6 deployment right now and I am trying to figure >>>> out >> >>>> our default allocation for customer LAN blocks. So what is everyone >>>> giving >> >>>> for a default LAN allocation for IPv6 Customers. I guess the idea of >> >>>> handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me >> >>>> cringe at the waste. Especially when you know 90% of customers will never >> >>>> have more than 2 or 3 subnets. As I see it the customer can always ask >>>> for >> >>>> more IPv6 Space. >> >>>> >> >>>> /64 >> >>>> /60 >> >>>> /56 >> >>>> /48 >> >>>> >> >>>> Small Customer? >> >>>> Medium Customer? >> >>>> Large Customer? >> >>>> >> >>>> Thanks >> >>>> >> >>>> Erik >> >>>> >> >>>> ________________________________ >> >>>> >> >>>> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, >>>> files >>>> or >> >>>> previous e-mail messages attached to it may contain confidential >>>> information >> >>>> that is legally privileged. If you are not the intended recipient, or a >> >>>> person responsible for delivering it to the intended recipient, you are >> >>>> hereby notified that any disclosure, copying, distribution or use of any >>>> of >> >>>> the information contained in or attached to this transmission is STRICTLY >> >>>> PROHIBITED. If you have received this transmission in error please notify >> >>>> the sender immediately by replying to this e-mail. You must destroy the >> >>>> original transmission and its attachments without reading or saving in >>>> any >> >>>> manner. Thank you. >> >>>> >> From owen at delong.com Thu Oct 9 07:37:05 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:37:05 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009065420.GA26275@pob.ytti.fi> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <20141009065420.GA26275@pob.ytti.fi> Message-ID: On Oct 8, 2014, at 11:54 PM, Saku Ytti wrote: > On (2014-10-09 15:25 +1100), Mark Andrews wrote: > > Hi, > >> Because /64 only allows for a single subnet running SLAAC with >> currently defined specifications. > > I fully agree that larger than 64 must be allocation, in mobile internet, > residental DSL, everywhere. I don't think it will happen, but I think it > should and I'm happy to say that I was able to impact the national regulatory > authority to include this in their recommendation for how IPv6 should be > provided. Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed. > Having routable network is only benefit of IPv6 over IPv4, and if we just give > customers connected /64 network, without routing /56 there, then customers > will need NAT. It’s not the only benefit, it is one of many benefits. Owen From owen at delong.com Thu Oct 9 07:34:08 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:34:08 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009050623.GB15355@bamboo.slabnet.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <20141009050623.GB15355@bamboo.slabnet.com> Message-ID: On Oct 8, 2014, at 10:06 PM, Hugo Slabbert wrote: > Mark, > >>> >Only short sighted ISP's hand out /56's to residential customers. > >>> >>> I am curious as to why you say it is short sighted? what is the technical or >>> otherwise any other reasoning for such statement ? >> >> 256 is *not* a big number of subnets. By restricting the number >> of subnets residences get you restrict what developers will design >> for. Subnets don't need to be scares resource. ISP's that default to >> /56 are making them a scares resource. > > The excerpt Royce quoted from RFC6177 (requoted below) seems to back away from /48s by default to all resi users and land in a somewhat vague "more than a /64 please, but we're not specifically recommending /48s across the board for residential" before specifically mentioning /56 assignments. Yes, but if you review the record as 6177 was rammed through against somewhat vociferous objection to this part, you should realize that that part really didn’t achieve near the level of consensus that should have been required for it to be accepted. > The general push in the community is towards /48 across the board. Any comments on why the RFC backs away from that? Is this just throwing a bone to the masses complaining about "waste”? It was a political maneuver to appease the IPv4 thinkers that were prevalent in that part of the IETF at the time. (Just my opinion). Owen From owen at delong.com Thu Oct 9 07:40:33 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 00:40:33 -0700 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54363645.40507@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0v6v1p00s1cZc5601v6yGq> <54363645.40507@cox.net> Message-ID: <96AE4ED1-2A39-402F-9DC0-14C8CC53492A@delong.com> On Oct 9, 2014, at 12:16 AM, Larry Sheldon wrote: > On 10/9/2014 02:03, Owen DeLong wrote: >> >> On Oct 8, 2014, at 2:11 PM, William Herrin wrote: >> >>> On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli wrote: >>>> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>>>> On 10/8/2014 08:47, William Herrin wrote: >>>>>> BART would not have had an FCC license. They'd have had contracts with >>>>>> the various phone companies to co-locate equipment and provide wired >>>>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>>>> breach of contract, and that only if the cell phone companies decided >>>>>> their behavior was inconsistent with the SLA.. >>>>> >>>>> OK that makes more sense than the private answer I got from Roy. I >>>>> wondered why the FCC didn't take action if there was a license violation. >>>> >>>> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 >>> >>>> From the article: "Among the issues on which the F.C.C. is seeking >>> comment is whether it even has authority over the issue." >>> >>> Also: "The BART system owns the wireless transmitters and receivers >>> that allow for cellphone reception within its network.” >> >> I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. >> >>> I'm not entirely clear how that works. >> >> If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. > > What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? The translator had to be operated by a holder of an FCC license for that translator. Operator and Owner are not necessarily linked in any way shape or form, though they usually were one and the same. Owen From saku at ytti.fi Thu Oct 9 07:44:51 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Oct 2014 10:44:51 +0300 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <20141009065420.GA26275@pob.ytti.fi> Message-ID: <20141009074451.GA1269@pob.ytti.fi> On (2014-10-09 00:37 -0700), Owen DeLong wrote: > Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed. According to the national IPv6 residential recommendation 3GPP release 10 offers prefix delegation, which will facilitate this. > > Having routable network is only benefit of IPv6 over IPv4, and if we just give > > customers connected /64 network, without routing /56 there, then customers > > will need NAT. > > It’s not the only benefit, it is one of many benefits. Yeah mailing list volume is the other one. -- ++ytti From kauer at biplane.com.au Thu Oct 9 07:50:07 2014 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 09 Oct 2014 18:50:07 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net> Message-ID: <1412841007.20084.115.camel@karl> On Thu, 2014-10-09 at 04:59 +0000, Peter Rocca wrote: > To paraphrase a post on this list a while ago (my apologies for lack of reference). > There are two kinds of waste: > - the first kind of waste is providing 'too many' subnets for someone; > - the second kind of waste is leaving the space unallocated forever. Good point. But I maintain that "too many" is exactly the right number, and not a waste at all :-) There are only three amounts of any scarce resource - too little, enough, and "I don't know". In an ideal world nobody knows how much disk space, RAM, bandwidth or address space they have - they never run into their limits. IPv6 has ticked the box for address space - why are so many people intent on unticking it? In my courses on IPv6, "wasted address space" *always* comes up. I define waste as spending some finite resource for no benefit. With IPv6, the resource is extremely abundant, though admittedly not infinite. And the benefits from handing out big allocations are numerous: - never resize an allocation - never have to add an allocation - never have to take a phone call asking to resize an allocation - all prefixes are the same length - easier, faster, simpler to allocate, manage, filter, firewall, document... ... and that's just to start with. It all translates into cheaper, easier, less error-prone. And the benefits are reaped by both parties - the provider and the customer. There's a case to be made, also, that simpler is more secure, because simpler and more homogeneous networks are easier to understand, easier to manage, and this suffer less from human error and so on. This is what you are buying with short prefixes. There are clear benefits, so it's not "waste". There's another point though, that I may have made before in this forum, and that is that whether you have 2, 200 or 2000 nodes in a /64, you are still using, to many decimal places, zero percent of the available address space. The number of live nodes is barely even statistical noise. So worrying about *addresses* in IPv6 is completely pointless. Thinking about subnets, on the other hand, does make sense - and 256 subnets (in a /56) is not very many. It's trivially easy to dream up an entirely plausible scenario where an ordinary household chews through that many subnets before breakfast. Give them a /48! Give everyone a /48. There is *enough address space* for goodness sake. All you are doing by "saving space" is putting a completely unnecessary brake on the future - yours and theirs. Give them more subnets, literally, than they or you know what to do with. So many that we can't even conceive of anyone using that many. That way subnets, like addresses, cease to be a limitation. "How many subnets do you have?" "I don't know - does it matter?" That's where you want to be. Don't let your limited vision limit other people. Even if YOU can't see the point, rest assured that some bright young thing just leaving high school will dream up something world-changingly wonderful that needs ten thousand subnets per household... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From swmike at swm.pp.se Thu Oct 9 07:54:07 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Oct 2014 09:54:07 +0200 (CEST) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <20141009065420.GA26275@pob.ytti.fi> Message-ID: On Thu, 9 Oct 2014, Owen DeLong wrote: > Sadly there are pieces of 3GPP that limit LTE to single /64 already. > These should, IMHO, be fixed. DHCPv6-PD is already standardized in 3GPP several years ago, it just hasn't made it widely into equipment out there yet. That's why current "best way" to do this is to share the /64 between the PDP context and the LAN. This of course is quite limiting, but it wouldn't surprise me if we'll see differentiation here between "mobile Internet" and regular "handset Internet" subscriptions unfortunately. I fully support giving all devices whatever they request, stop differentiating between different kinds of devices, and just charge where the costs are, ie on packets moved. -- Mikael Abrahamsson email: swmike at swm.pp.se From larrysheldon at cox.net Thu Oct 9 07:57:54 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 02:57:54 -0500 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <0vje1p00f02ea4o01vjjsg> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0v6v1p00s1cZc5601v6yGq> <54363645.40507@cox.net> <0vje1p00f02ea4o01vjjsg> Message-ID: <54364002.1010102@cox.net> On 10/9/2014 02:40, Owen DeLong wrote: >> What where the laws and practices in the Olde Days of over-the-air >> TV when somebody in a small town installed a translator to repeat >> Big-Cities-TV-Station into a small town? > > The translator had to be operated by a holder of an FCC license for > that translator. > > Operator and Owner are not necessarily linked in any way shape or > form, though they usually were one and the same. Was the translator operator obligated to carry everything from the source station, or could they turn the translator off if they wanted to? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From baldur.norddahl at gmail.com Thu Oct 9 07:58:56 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 09:58:56 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> Message-ID: We assign a /128 by DHCPv6 (*). And then we assign a /48 by DHCPv6-PD prefix delegation. To everyone no matter what class of customer they are. You are thinking about it wrong. It is not about what the customer need but about what you need. Do you really have a need to use more than 48 bits for your routing? Do we need more than 48 bits for the global routing table? Do we need more than 48 bits to conserve enough address space for any conceivable future setting? The answer is no to all of these, so why are you trying to decide what a user could be doing with the remaining address bits? What if IPv6 had been designed with a variable address length, such that you could do 2048 bits addresses if you wanted. What prefix length would you choose if that was the case? Where do you stop? Would you really be giving out /1024 because otherwise it would be "wasteful"? No, I believe you would be giving out /48s. (*) using /128 on the subscriber link solves a security issue and makes deployments on asymmetric links easier. Again we are doing it because of operational issues and not because we are trying to conserve address space. Regrads, Baldur On 9 October 2014 03:18, Erik Sundberg wrote: > I am planning out our IPv6 deployment right now and I am trying to figure > out our default allocation for customer LAN blocks. So what is everyone > giving for a default LAN allocation for IPv6 Customers. I guess the idea > of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me > cringe at the waste. Especially when you know 90% of customers will never > have more than 2 or 3 subnets. As I see it the customer can always ask for > more IPv6 Space. > > /64 > /60 > /56 > /48 > > Small Customer? > Medium Customer? > Large Customer? > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From md1clv at md1clv.com Thu Oct 9 08:46:48 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Thu, 9 Oct 2014 09:46:48 +0100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009044007.A75E6212E0D1@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> Message-ID: On 9 October 2014 05:40, Mark Andrews wrote: > > In message < > 482678376.131852.1412829159356.JavaMail.zimbra at snappytelecom.net>, > Faisal Imtiaz writes: > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the > technical or > > otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number > of subnets residences get you restrict what developers will design > for. Subnets don't need to be scares resource. ISP's that default to > /56 are making them a scares resource. My moment of clarity came when I got a /56 routed to my house and started using it. I started off thinking that 256 was a huge number of subnets, more than I could ever need. What I realised was that (sticking to best practices) a /56 only allows you one further level of delegation, and I found that to be more of a barrier than the number of subnets. In the same way that you stop thinking "/64 is a lot of addresses" and start thinking "/64 is a network" I find it helps to stop thinking "/48 is 65536 subnets" and start thinking "/48 allows you up to 4 levels of delegation." Dan From kauer at biplane.com.au Thu Oct 9 09:04:11 2014 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 09 Oct 2014 20:04:11 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> <20141009042528.7B65C212DE0A@rock.dv.isc.org> <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net> <20141009044007.A75E6212E0D1@rock.dv.isc.org> Message-ID: <1412845451.20084.136.camel@karl> On Thu, 2014-10-09 at 09:46 +0100, Daniel Ankers wrote: > What I realised was that (sticking to best practices) You mean "subnet only on 4-bit boundaries"? Nibble boundaries are nice for human readability, but if there is a good technical reason for other boundaries, you shouldn't shy away from them. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From bmanning at isi.edu Thu Oct 9 09:09:54 2014 From: bmanning at isi.edu (manning bill) Date: Thu, 9 Oct 2014 02:09:54 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009013115.CDFBF2116E22@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> Message-ID: <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> yes! by ALL means, hand out /48s. There is huge benefit to announcing all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 8October2014Wednesday, at 18:31, Mark Andrews wrote: > > Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off > and put on the IPv6 glasses. Stop constraining your customers > because you feel that it is a waste. It is not a waste!!!! It > will also reduce the number of exceptions you need to process and > make over all administration easier. > > As for only two subnets, I expect lots of equipment to request > prefixes in the future not just traditional routers. It will have > descrete internal components which communicate using IPv6 and those > components need to talk to each other and the world. In a IPv4 > world they would be NAT'd. In a IPv6 world the router requests a > prefix. > > Mark > > In message <495D0934DA46854A9CA758393724D5906DA244 at NI-MAIL02.nii.ads>, Erik Sun > dberg writes: >> I am planning out our IPv6 deployment right now and I am trying to figure o= >> ut our default allocation for customer LAN blocks. So what is everyone givi= >> ng for a default LAN allocation for IPv6 Customers. I guess the idea of ha= >> nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cring= >> e at the waste. Especially when you know 90% of customers will never have m= >> ore than 2 or 3 subnets. As I see it the customer can always ask for more I= >> Pv6 Space. >> >> /64 >> /60 >> /56 >> /48 >> >> Small Customer? >> Medium Customer? >> Large Customer? >> >> Thanks >> >> Erik >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = >> or previous e-mail messages attached to it may contain confidential informa= >> tion that is legally privileged. If you are not the intended recipient, or = >> a person responsible for delivering it to the intended recipient, you are h= >> ereby notified that any disclosure, copying, distribution or use of any of = >> the information contained in or attached to this transmission is STRICTLY P= >> ROHIBITED. If you have received this transmission in error please notify th= >> e sender immediately by replying to this e-mail. You must destroy the origi= >> nal transmission and its attachments without reading or saving in any manne= >> r. Thank you. > -- > 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 Thu Oct 9 09:29:14 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Oct 2014 20:29:14 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 02:09:54 -0700." <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> Message-ID: <20141009092914.A04CE213074C@rock.dv.isc.org> In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567 at isi.edu>, manning bill writes: > yes! by ALL means, hand out /48s. There is huge benefit to announcing = > all that dark space, esp. when > virtually no one practices BCP-38, esp in IPv6 land. > > > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's. > On 8October2014Wednesday, at 18:31, Mark Andrews wrote: > > >=20 > > Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off > > and put on the IPv6 glasses. Stop constraining your customers > > because you feel that it is a waste. It is not a waste!!!! It > > will also reduce the number of exceptions you need to process and > > make over all administration easier. > >=20 > > As for only two subnets, I expect lots of equipment to request > > prefixes in the future not just traditional routers. It will have > > descrete internal components which communicate using IPv6 and those > > components need to talk to each other and the world. In a IPv4 > > world they would be NAT'd. In a IPv6 world the router requests a > > prefix. > >=20 > > Mark > >=20 > > In message <495D0934DA46854A9CA758393724D5906DA244 at NI-MAIL02.nii.ads>, = > Erik Sun > > dberg writes: > >> I am planning out our IPv6 deployment right now and I am trying to = > figure o=3D > >> ut our default allocation for customer LAN blocks. So what is = > everyone givi=3D > >> ng for a default LAN allocation for IPv6 Customers. I guess the idea = > of ha=3D > >> nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = > cring=3D > >> e at the waste. Especially when you know 90% of customers will never = > have m=3D > >> ore than 2 or 3 subnets. As I see it the customer can always ask for = > more I=3D > >> Pv6 Space. > >>=20 > >> /64 > >> /60 > >> /56 > >> /48 > >>=20 > >> Small Customer? > >> Medium Customer? > >> Large Customer? > >>=20 > >> Thanks > >>=20 > >> Erik > >>=20 > >> ________________________________ > >>=20 > >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = > files =3D > >> or previous e-mail messages attached to it may contain confidential = > informa=3D > >> tion that is legally privileged. If you are not the intended = > recipient, or =3D > >> a person responsible for delivering it to the intended recipient, you = > are h=3D > >> ereby notified that any disclosure, copying, distribution or use of = > any of =3D > >> the information contained in or attached to this transmission is = > STRICTLY P=3D > >> ROHIBITED. If you have received this transmission in error please = > notify th=3D > >> e sender immediately by replying to this e-mail. You must destroy the = > origi=3D > >> nal transmission and its attachments without reading or saving in any = > manne=3D > >> r. Thank you. > > --=20 > > 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 jayfar at jayfar.com Thu Oct 9 10:38:45 2014 From: jayfar at jayfar.com (Jay Farrell) Date: Thu, 9 Oct 2014 06:38:45 -0400 Subject: OT: A certain WISP operator puts Sir Tim in his place Message-ID: Noted, with some amusement, in the comments to a NY Times piece in which Sir Tim Berners-Lee speaks out for net neutrality: http://bits.blogs.nytimes.com/2014/10/08/tim-berners-lee-web-creator-defends-net-neutrality/ --quote-- Brett Glass Laramie, WY 16 hours ago Berners-Lee is an Internet application developer (he developed an early one that was never commercially successful -- in fact, no Web browser has been commercially successful -- but important nonetheless). He thus has the biases of one. He has never worked as an ISP, operated an ISP, or managed an Internet service. [snip] --end quote From paigeadele at gmail.com Thu Oct 9 11:00:09 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Thu, 09 Oct 2014 14:00:09 +0300 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009092914.A04CE213074C@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> Message-ID: <54366AB9.3040504@gmail.com> makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. On 10/09/14 12:29, Mark Andrews wrote: > In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567 at isi.edu>, manning bill writes: >> yes! by ALL means, hand out /48s. There is huge benefit to announcing = >> all that dark space, esp. when >> virtually no one practices BCP-38, esp in IPv6 land. >> >> >> /bill >> PO Box 12317 >> Marina del Rey, CA 90295 >> 310.322.8102 > and if everyone hands out /48's you just filter /48's. With a mix of /56 > and /48 you need to filter at the /56 level. Given enterpises are getting > /48's it will be simpler overall for everyone to get /48's. > >> On 8October2014Wednesday, at 18:31, Mark Andrews wrote: >> >>> =20 >>> Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off >>> and put on the IPv6 glasses. Stop constraining your customers >>> because you feel that it is a waste. It is not a waste!!!! It >>> will also reduce the number of exceptions you need to process and >>> make over all administration easier. >>> =20 >>> As for only two subnets, I expect lots of equipment to request >>> prefixes in the future not just traditional routers. It will have >>> descrete internal components which communicate using IPv6 and those >>> components need to talk to each other and the world. In a IPv4 >>> world they would be NAT'd. In a IPv6 world the router requests a >>> prefix. >>> =20 >>> Mark >>> =20 >>> In message <495D0934DA46854A9CA758393724D5906DA244 at NI-MAIL02.nii.ads>, = >> Erik Sun >>> dberg writes: >>>> I am planning out our IPv6 deployment right now and I am trying to = >> figure o=3D >>>> ut our default allocation for customer LAN blocks. So what is = >> everyone givi=3D >>>> ng for a default LAN allocation for IPv6 Customers. I guess the idea = >> of ha=3D >>>> nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = >> cring=3D >>>> e at the waste. Especially when you know 90% of customers will never = >> have m=3D >>>> ore than 2 or 3 subnets. As I see it the customer can always ask for = >> more I=3D >>>> Pv6 Space. >>>> =20 >>>> /64 >>>> /60 >>>> /56 >>>> /48 >>>> =20 >>>> Small Customer? >>>> Medium Customer? >>>> Large Customer? >>>> =20 >>>> Thanks >>>> =20 >>>> Erik >>>> =20 >>>> ________________________________ >>>> =20 >>>> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = >> files =3D >>>> or previous e-mail messages attached to it may contain confidential = >> informa=3D >>>> tion that is legally privileged. If you are not the intended = >> recipient, or =3D >>>> a person responsible for delivering it to the intended recipient, you = >> are h=3D >>>> ereby notified that any disclosure, copying, distribution or use of = >> any of =3D >>>> the information contained in or attached to this transmission is = >> STRICTLY P=3D >>>> ROHIBITED. If you have received this transmission in error please = >> notify th=3D >>>> e sender immediately by replying to this e-mail. You must destroy the = >> origi=3D >>>> nal transmission and its attachments without reading or saving in any = >> manne=3D >>>> r. Thank you. >>> --=20 >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From james.cutler at consultant.com Thu Oct 9 13:36:33 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 9 Oct 2014 09:36:33 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net> <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net> Message-ID: <41009A70-1DC0-4C5A-A782-C8A9D3A09F03@consultant.com> On Oct 9, 2014, at 12:07 AM, Faisal Imtiaz wrote: > So, let me ask the question in a different manner... > What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). The wisdom/reasoning behind larger allocations is to control the cost of doing business. Things change. Customer requirements change. Arrange your network so that customers can do what they need without configuration costs on your part. Follow the money. Then keep it. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From marka at isc.org Thu Oct 9 13:56:58 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Oct 2014 00:56:58 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: Your message of "Thu, 09 Oct 2014 14:00:09 +0300." <54366AB9.3040504@gmail.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> Message-ID: <20141009135658.EF0432132042@rock.dv.isc.org> In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes: > makes more sense to hand out /48s imho. theres only a mere 65k /48s per > /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nathaniel.wingard at aciworldwide.com Thu Oct 9 14:02:21 2014 From: nathaniel.wingard at aciworldwide.com (Nathaniel Wingard) Date: Thu, 9 Oct 2014 10:02:21 -0400 Subject: Paetech Routing Loop Message-ID: Is there a Paetech/Windstream tech that could help me with a routing loop in New Hampshire? Thanks, Nathaniel -- This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. From owen at delong.com Thu Oct 9 14:11:34 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 10:11:34 -0400 Subject: wifi blocking [was Re: Marriott wifi blocking] In-Reply-To: <54364002.1010102@cox.net> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <54305C14.1000907@mtcc.com> <76E78678-F9DF-4563-9D94-8302BFDFEA9A@delong.com> <5430E3D9.3010900@mtcc.com> <2C4EA5E9-5CB8-45FE-A522-77C89098F34E@delong.com> <5432B010.1070302@mtcc.com> <7EA5BCEB-E331-4A81-B56F-1BEBCA260902@delong.com> <5432D219.5050701@mtcc.com> <54348528.9060708@cox.net> <543488AF.40806@stargate.ca> <35458.1412732186@turing-police.cc.vt.edu> <5434A2B6.7000007@cox.net> <5434B927.8080400@cox.net> <5434CD19.8050704@cox.net> <54353127.4060406@gmail.com> <54359EB3.9090909@cox.net> <5435A093.5070501@bogus.com> <0v6v1p00s1cZc5601v6yGq> <54363645.40507@cox.net> <0vje1p00f02ea4o01vjjsg> <54364002.1010102@cox.net> Message-ID: > On Oct 9, 2014, at 03:57, Larry Sheldon wrote: > > On 10/9/2014 02:40, Owen DeLong wrote: > >>> What where the laws and practices in the Olde Days of over-the-air >>> TV when somebody in a small town installed a translator to repeat >>> Big-Cities-TV-Station into a small town? >> >> The translator had to be operated by a holder of an FCC license for >> that translator. >> >> Operator and Owner are not necessarily linked in any way shape or >> form, though they usually were one and the same. > > Was the translator operator obligated to carry everything from the source station, or could they turn the translator off if they wanted to? I honestly don't know what the license terms were. I am also not aware of any circumstances where that issue was at all likely to come up. Owen > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes From corbe at corbe.net Thu Oct 9 14:22:29 2014 From: corbe at corbe.net (Daniel Corbe) Date: Thu, 09 Oct 2014 10:22:29 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009135658.EF0432132042@rock.dv.isc.org> (Mark Andrews's message of "Fri, 10 Oct 2014 00:56:58 +1100") References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> Message-ID: Mark Andrews writes: > In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes: >> makes more sense to hand out /48s imho. theres only a mere 65k /48s per >> /32 (or something like that), though. > > A /32 is the minimum allocation to a ISP. If you have more customers > or will have more customers request a bigger block from the RIRs. > > Mark Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face. From owen at delong.com Thu Oct 9 14:19:16 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 10:19:16 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <54366AB9.3040504@gmail.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> Message-ID: Policy allows any ISP (LIR) with need greater than /32 to easily qualify for what they need up to /12. I know of at least two entities that have applied for and with minimal effort and appropriate justification, received /24 allocations and many with /28s. Owen > On Oct 9, 2014, at 07:00, Paige Thompson wrote: > > makes more sense to hand out /48s imho. theres only a mere 65k /48s per > /32 (or something like that), though. > > >> On 10/09/14 12:29, Mark Andrews wrote: >> In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567 at isi.edu>, manning bill writes: >>> yes! by ALL means, hand out /48s. There is huge benefit to announcing = >>> all that dark space, esp. when >>> virtually no one practices BCP-38, esp in IPv6 land. >>> >>> >>> /bill >>> PO Box 12317 >>> Marina del Rey, CA 90295 >>> 310.322.8102 >> and if everyone hands out /48's you just filter /48's. With a mix of /56 >> and /48 you need to filter at the /56 level. Given enterpises are getting >> /48's it will be simpler overall for everyone to get /48's. >> >>>> On 8October2014Wednesday, at 18:31, Mark Andrews wrote: >>>> >>>> =20 >>>> Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off >>>> and put on the IPv6 glasses. Stop constraining your customers >>>> because you feel that it is a waste. It is not a waste!!!! It >>>> will also reduce the number of exceptions you need to process and >>>> make over all administration easier. >>>> =20 >>>> As for only two subnets, I expect lots of equipment to request >>>> prefixes in the future not just traditional routers. It will have >>>> descrete internal components which communicate using IPv6 and those >>>> components need to talk to each other and the world. In a IPv4 >>>> world they would be NAT'd. In a IPv6 world the router requests a >>>> prefix. >>>> =20 >>>> Mark >>>> =20 >>>> In message <495D0934DA46854A9CA758393724D5906DA244 at NI-MAIL02.nii.ads>, = >>> Erik Sun >>>> dberg writes: >>>>> I am planning out our IPv6 deployment right now and I am trying to = >>> figure o=3D >>>>> ut our default allocation for customer LAN blocks. So what is = >>> everyone givi=3D >>>>> ng for a default LAN allocation for IPv6 Customers. I guess the idea = >>> of ha=3D >>>>> nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = >>> cring=3D >>>>> e at the waste. Especially when you know 90% of customers will never = >>> have m=3D >>>>> ore than 2 or 3 subnets. As I see it the customer can always ask for = >>> more I=3D >>>>> Pv6 Space. >>>>> =20 >>>>> /64 >>>>> /60 >>>>> /56 >>>>> /48 >>>>> =20 >>>>> Small Customer? >>>>> Medium Customer? >>>>> Large Customer? >>>>> =20 >>>>> Thanks >>>>> =20 >>>>> Erik >>>>> =20 >>>>> ________________________________ >>>>> =20 >>>>> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = >>> files =3D >>>>> or previous e-mail messages attached to it may contain confidential = >>> informa=3D >>>>> tion that is legally privileged. If you are not the intended = >>> recipient, or =3D >>>>> a person responsible for delivering it to the intended recipient, you = >>> are h=3D >>>>> ereby notified that any disclosure, copying, distribution or use of = >>> any of =3D >>>>> the information contained in or attached to this transmission is = >>> STRICTLY P=3D >>>>> ROHIBITED. If you have received this transmission in error please = >>> notify th=3D >>>>> e sender immediately by replying to this e-mail. You must destroy the = >>> origi=3D >>>>> nal transmission and its attachments without reading or saving in any = >>> manne=3D >>>>> r. Thank you. >>>> --=20 >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From faisal at snappytelecom.net Thu Oct 9 14:31:39 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 14:31:39 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> Message-ID: <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> > > Selection of a default prefix is easy. Here are the steps. > > > > 4. Keeping in mind > > > > 4.1 Prefixes longer than somewhere around /48 to /56 may be > > excluded from the global routing table > > 4.1a Prefix cutouts of any size (including /48) from inside your /32 > or larger block may be excluded from the global routing table. Folks > who are multihomed and thus need to advertise their own block with BGP > should be referred to ARIN for a direct assignment. Folks who aren't > multihomed, well, until given evidence otherwise I claim there are no > single-homed entities who will use 65,000 LANs, let alone more. ============================================= This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Regards Faisal Imtiaz Snappy Internet & Telecom From karsten.elfenbein at gmail.com Thu Oct 9 14:34:15 2014 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Thu, 9 Oct 2014 16:34:15 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> Message-ID: 2014-10-09 16:22 GMT+02:00 Daniel Corbe : > Has anyone successfully gotten a RIR to assign anything bigger than a > /32? I seem to recall in recent history someone tried to obtain a /31 > through ARIN and got smacked down. > > Even if you're assigning a /56 to every end user, that's still on the > order of 16 million allocations. I can't imagine anyone but the truly > behemoth access network operators being able to justify a larger > allocation with a straight face. > Ripe is handing out /29 without any additional documentation current IPv4 usage documentation should do the trick to request larger blocks for deployment of /48 to customers From rdobbins at arbor.net Thu Oct 9 14:35:33 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 9 Oct 2014 21:35:33 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <20141009013115.CDFBF2116E22@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> Message-ID: <34E6F9E9-C3C2-4D40-9589-4B3439EB9715@arbor.net> On Oct 9, 2014, at 8:31 AM, Mark Andrews wrote: > As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. I'm expecting every molecule in every compound to have an embedded IPv6 address which can be read via NFC or some similar technology; and every nanomachine which is pumped into every heart patient to clear out arterial plaque to have one; and every windowblind in every window in every house and apartment and condominium and so forth to have one; etc. And for the vast majority of those addresses to be limited-duration, one-time-use addresses, and for their address space never to be recovered and resubmitted back into the free address pool. Which is one reason why I think that this trend of encouraging overly profligate allocation of IPv6 addresses is ill-considered. We've already seen the folly of /64s for point-to-point links in terms of turning routers and layer-3 switches into sinkholes. Do we really want to turn each and every network, no matter how small, into a 'strange attractor' for potentially significant amounts of irrelevant and undesirable traffic? Yes, I fully understand how huge the IPv6 address space really is - but I also believe that the general conception of what will constitute a node is extremely shortsighted, even by those who are evangelizing the so-called 'Internet of Things', and that a huge proportion of the IPv6 address space will eventually end up being allocated for limited-duration, one-time use in applications such as those cited above. I also believe that we need to drastically expand our projected timescales for the utility of IPv6, while keeping those address-hungry potential applications in mind. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From rdobbins at arbor.net Thu Oct 9 14:39:40 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 9 Oct 2014 21:39:40 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> Message-ID: <1183F513-5ECB-48B9-A06B-18572D3EB73B@arbor.net> On Oct 9, 2014, at 2:15 PM, Owen DeLong wrote: > Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. On the contrary, I believe that the increase in the potential address pool size will lead to much flatter, less hierarchical networks - while at the same time leading to most nodes being highly multi-homed into various virtual topologies, thereby leading to significant increases of addresses per node. A 'node' being things like molecules, nanites, window blinds, soda cans, etc. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From contact at winterei.se Thu Oct 9 14:41:56 2014 From: contact at winterei.se (Paul S.) Date: Thu, 09 Oct 2014 23:41:56 +0900 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> Message-ID: <54369EB4.4010306@winterei.se> I've been using /36s per location, but hm -- great question. How easy is it to get a larger allocation anyway? In RIPE, i.e: you just ask and get a /29 with no questions asked. On 10/9/2014 午後 11:31, Faisal Imtiaz wrote: >>> Selection of a default prefix is easy. Here are the steps. >>> >>> 4. Keeping in mind >>> >>> 4.1 Prefixes longer than somewhere around /48 to /56 may be >>> excluded from the global routing table >> 4.1a Prefix cutouts of any size (including /48) from inside your /32 >> or larger block may be excluded from the global routing table. Folks >> who are multihomed and thus need to advertise their own block with BGP >> should be referred to ARIN for a direct assignment. Folks who aren't >> multihomed, well, until given evidence otherwise I claim there are no >> single-homed entities who will use 65,000 LANs, let alone more. > ============================================= > > This brings up another interesting question... > > We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. > > Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? > > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom From kauer at biplane.com.au Thu Oct 9 14:47:27 2014 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Oct 2014 01:47:27 +1100 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> Message-ID: <1412866047.20084.235.camel@karl> On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: > Has anyone successfully gotten a RIR to assign anything bigger than a > /32? I seem to recall in recent history someone tried to obtain a /31 > through ARIN and got smacked down. Legend has it that the US DOD applied for a /8 - and got smacked down :-) > Even if you're assigning a /56 to every end user, that's still on the > order of 16 million allocations. If, as you should be, you are assigning /48s, it's only 65536. Not that big. That's why it's the *minimum* allocation. Larger allocations are possible and I suspect quite common. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From cb.list6 at gmail.com Thu Oct 9 15:11:41 2014 From: cb.list6 at gmail.com (Ca By) Date: Thu, 9 Oct 2014 08:11:41 -0700 Subject: NANOG Digest, Vol 81, Issue 7 In-Reply-To: <076801cfe24e$cbf0dc00$63d29400$@net> References: <076801cfe24e$cbf0dc00$63d29400$@net> Message-ID: www.socialsecurity.gov still down on ipv6. Still looping. wget -6 -T 5 www.socialsecurity.gov --2014-10-09 08:07:23-- http://www.socialsecurity.gov/ Resolving www.socialsecurity.gov (www.socialsecurity.gov)... 2001:1930:c01::aaaa, 2001:1930:e03::aaaa Connecting to www.socialsecurity.gov (www.socialsecurity.gov)|2001:1930:c01::aaaa|:80... failed: Operation timed out. Connecting to www.socialsecurity.gov (www.socialsecurity.gov)|2001:1930:e03::aaaa|:80... failed: Operation timed out. Retrying. traceroute6 2001:1930:c01::aaaa traceroute6 to 2001:1930:c01::aaaa (2001:1930:c01::aaaa) from 2607:f2f8:a8e0::2, 64 hops max, 12 byte packets 1 2607:f2f8:a8e0::1 5.481 ms 4.120 ms 0.888 ms 2 ge-0-7-0-24.r04.lsanca03.us.bb.gin.ntt.net 1.328 ms 1.191 ms 0.971 ms 3 2001:428:201:8::1 0.730 ms 0.972 ms 0.965 ms 4 2001:428::205:171:3:171 74.438 ms 73.648 ms 73.578 ms 5 2001:428:a202::2:0:2 82.113 ms 81.696 ms 82.507 ms 6 www.socialsecurity.gov 76.489 ms 75.912 ms 76.092 ms 7 2001:1930:c01::2 77.230 ms 77.517 ms 77.573 ms 8 www.socialsecurity.gov 76.595 ms 76.783 ms 76.536 ms 9 2001:1930:c01::2 77.330 ms 77.325 ms 76.834 ms 10 www.socialsecurity.gov 76.028 ms 76.094 ms 76.156 ms 11 2001:1930:c01::2 77.089 ms 77.477 ms 77.358 ms 12 www.socialsecurity.gov 77.186 ms 76.257 ms 76.257 ms 13 2001:1930:c01::2 77.438 ms 77.671 ms 77.424 ms 14 www.socialsecurity.gov 76.345 ms 75.991 ms 76.521 ms 15 2001:1930:c01::2 77.219 ms 77.347 ms 77.293 ms 16 www.socialsecurity.gov 76.209 ms 76.082 ms 76.115 ms 17 2001:1930:c01::2 77.138 ms 77.717 ms 77.285 ms 18 www.socialsecurity.gov 76.459 ms 76.266 ms 76.355 ms 19 2001:1930:c01::2 77.425 ms 77.231 ms 77.310 ms 20 www.socialsecurity.gov 76.473 ms 76.557 ms 76.285 ms 21 2001:1930:c01::2 77.579 ms 77.708 ms 77.680 ms 22 www.socialsecurity.gov 76.474 ms 76.767 ms 76.532 ms 23 2001:1930:c01::2 106.244 ms 78.282 ms 77.578 ms 24 www.socialsecurity.gov 76.476 ms 76.617 ms 77.532 ms 25 2001:1930:c01::2 77.810 ms 77.645 ms 77.950 ms 26 www.socialsecurity.gov 77.590 ms 76.605 ms 76.981 ms 27 2001:1930:c01::2 77.710 ms 77.766 ms 78.306 ms On Tue, Oct 7, 2014 at 9:50 AM, Ralph Wallace wrote: > > > < < > CAD6AjGQHhRBZiFRNwH+_Dy1WoE8hXxHErNq0CT-pw+iQvVUqOA at mail.gmail.com> > > > ~Attempting to work this through the Federal IPv6 Task Force and the SSA > IPv6 Transition Manager~ > > > > From trejrco at gmail.com Thu Oct 9 15:45:54 2014 From: trejrco at gmail.com (TJ) Date: Thu, 9 Oct 2014 11:45:54 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1412866047.20084.235.camel@karl> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <1412866047.20084.235.camel@karl> Message-ID: > On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: > > Has anyone successfully gotten a RIR to assign anything bigger than a > > /32? I seem to recall in recent history someone tried to obtain a /31 > > through ARIN and got smacked down. > > Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13. Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html /TJ From bill at herrin.us Thu Oct 9 15:56:06 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 11:56:06 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> Message-ID: On Thu, Oct 9, 2014 at 10:34 AM, Karsten Elfenbein wrote: > Ripe is handing out /29 without any additional documentation > current IPv4 usage documentation should do the trick to request larger > blocks for deployment of /48 to customers And /19s with documentation. Europe will by God not end up with fewer IPv6 addresses than the U.S. like has happened with IPv4. -Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From owen at delong.com Thu Oct 9 16:01:45 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 09:01:45 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> Message-ID: <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> On Oct 9, 2014, at 7:22 AM, Daniel Corbe wrote: > > Mark Andrews writes: > >> In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes: >>> makes more sense to hand out /48s imho. theres only a mere 65k /48s per >>> /32 (or something like that), though. >> >> A /32 is the minimum allocation to a ISP. If you have more customers >> or will have more customers request a bigger block from the RIRs. >> >> Mark > > Has anyone successfully gotten a RIR to assign anything bigger than a > /32? I seem to recall in recent history someone tried to obtain a /31 > through ARIN and got smacked down. I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations. > Even if you're assigning a /56 to every end user, that's still on the > order of 16 million allocations. I can't imagine anyone but the truly > behemoth access network operators being able to justify a larger > allocation with a straight face. You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations. Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution. ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU). Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48. All of your utilization is measured in terms of PAUs. You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs. Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16. Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well. That is the size of allocation you can get from ARIN. So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12. Obviously this is an unusually large example. At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers. This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16. I hope that clarifies things for people. Owen From owen at delong.com Thu Oct 9 16:20:14 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 09:20:14 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> Message-ID: <5E33293C-2094-4779-B1DF-5FC89B07B7E5@delong.com> On Oct 9, 2014, at 7:31 AM, Faisal Imtiaz wrote: >>> Selection of a default prefix is easy. Here are the steps. >>> >>> 4. Keeping in mind >>> >>> 4.1 Prefixes longer than somewhere around /48 to /56 may be >>> excluded from the global routing table >> >> 4.1a Prefix cutouts of any size (including /48) from inside your /32 >> or larger block may be excluded from the global routing table. Folks >> who are multihomed and thus need to advertise their own block with BGP >> should be referred to ARIN for a direct assignment. Folks who aren't >> multihomed, well, until given evidence otherwise I claim there are no >> single-homed entities who will use 65,000 LANs, let alone more. > ============================================= > > This brings up another interesting question... > > We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. > > Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Depends on your needs… Either is a viable solution, depending on your circumstances. ARIN has an MDN policy which would facilitate your acquisition of a second /32. Owen From richard.hicks at gmail.com Thu Oct 9 16:29:21 2014 From: richard.hicks at gmail.com (Richard Hicks) Date: Thu, 9 Oct 2014 09:29:21 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? http://bcop.nanog.org/index.php/IPv6_Subnetting As we recently discovered ARIN is handing out IPv6 allocations on nibble boundaries. Either a /32 or /28 for service providers. A justification and utilization plan is need to get a /28. It is also double the cost per year. On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong wrote: > > On Oct 9, 2014, at 7:22 AM, Daniel Corbe wrote: > > > > > Mark Andrews writes: > > > >> In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes: > >>> makes more sense to hand out /48s imho. theres only a mere 65k /48s per > >>> /32 (or something like that), though. > >> > >> A /32 is the minimum allocation to a ISP. If you have more customers > >> or will have more customers request a bigger block from the RIRs. > >> > >> Mark > > > > Has anyone successfully gotten a RIR to assign anything bigger than a > > /32? I seem to recall in recent history someone tried to obtain a /31 > > through ARIN and got smacked down. > > I think I answered this before you asked it, but yes,easily on multiple > occasions. The largest two allocations I have worked on were /24s, but I’m > sure > those are not ARIN’s largest allocations. > > > Even if you're assigning a /56 to every end user, that's still on the > > order of 16 million allocations. I can't imagine anyone but the truly > > behemoth access network operators being able to justify a larger > > allocation with a straight face. > > You should, however, be assigning a /48 to every end user and that’s only > 65,536 allocations. > > Further, you want to be able to aggregate at least one level in your > network, > so you may not be able to get anything close to 100% efficiency in that > distribution. > > ARIN policy, for example, defines what is known as a Provider Allocation > Unit (PAU). > > Your PAU is the smallest allocation you give to your customers, so if > you’re > giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then > your PAU is /56. As such, you’re better off to give /48s to everyone > because > that sets your PAU at /48. > > All of your utilization is measured in terms of PAUs. > > You then pick an aggregation level in your network to use as your “serving > center” > definition. It could be the POP, or some higher level of aggregation > containing > multiple POPs. > > Look at the number of end sites served by the largest of those “serving > centers” > and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, > 65536) > such that the number of end sites is not more than 75% of the chosen poser > of 16. > > Then take the number of “serving centers” you expect to have in ~5 years > (though > the exact forward looking time is not actually specified in policy) and > round that > up to a nibble boundary as well. > > That is the size of allocation you can get from ARIN. > > So, for example, if you have 800,000 end-sites served from your largest > POP and > you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 > bits) > and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up > needing 36 bits. If your PAU is /48, you would apply for and receive a /12. > > Obviously this is an unusually large example. > > At a more realistic large ISP scale, let’s say you’ve got 5,000,000 > subscribers in > your largest serving center, but only 25 serving centers. > > This would, again, round up to 16,777,216 (24 bits) subscribers per > serving center. > But your 25 serving centers would round up to 256 (8 bits). That’s 32 > bits, so instead > of a /12, you’d get a /16. > > > I hope that clarifies things for people. > > Owen > > > From joelja at bogus.com Thu Oct 9 16:30:03 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 09 Oct 2014 09:30:03 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <1412866047.20084.235.camel@karl> Message-ID: <5436B80B.4050409@bogus.com> On 10/9/14 8:45 AM, TJ wrote: >> On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: >>> Has anyone successfully gotten a RIR to assign anything bigger than a >>> /32? I seem to recall in recent history someone tried to obtain a /31 >>> through ARIN and got smacked down. >> >> > Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD > got the equivalent of a /13. > > Quick looks: > https://www.sixxs.net/tools/grh/dfp/ > http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html Many lir / provider assignments are shorter than a 32 you see them in bgp... http://bgp.he.net/AS701#_prefixes6 http://bgp.he.net/AS7922#_prefixes6 http://bgp.he.net/AS1299#_prefixes6 > > /TJ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Thu Oct 9 16:31:03 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 09:31:03 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1183F513-5ECB-48B9-A06B-18572D3EB73B@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> <1183F513-5ECB-48B9-A06B-18572D3EB73B@arbor.net> Message-ID: Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Owen On Oct 9, 2014, at 7:39 AM, Roland Dobbins wrote: > > On Oct 9, 2014, at 2:15 PM, Owen DeLong wrote: > >> Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. > > On the contrary, I believe that the increase in the potential address pool size will lead to much flatter, less hierarchical networks - while at the same time leading to most nodes being highly multi-homed into various virtual topologies, thereby leading to significant increases of addresses per node. > > A 'node' being things like molecules, nanites, window blinds, soda cans, etc. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön From owen at delong.com Thu Oct 9 16:32:56 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 09:32:56 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <1412866047.20084.235.camel@karl> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <1412866047.20084.235.camel@karl> Message-ID: It’s entirely likely that someone attempted to get a /31 from ARIN recently and they most definitely would have been smacked down, but not because they couldn’t get more than a /32. ARIN will not issue a /31 under current policy, but if you need more than ~48,000 end-sites, you easily qualify for a /28. Owen On Oct 9, 2014, at 7:47 AM, Karl Auer wrote: > On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: >> Has anyone successfully gotten a RIR to assign anything bigger than a >> /32? I seem to recall in recent history someone tried to obtain a /31 >> through ARIN and got smacked down. > > Legend has it that the US DOD applied for a /8 - and got smacked > down :-) > >> Even if you're assigning a /56 to every end user, that's still on the >> order of 16 million allocations. > > If, as you should be, you are assigning /48s, it's only 65536. Not that > big. That's why it's the *minimum* allocation. Larger allocations are > possible and I suspect quite common. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > From rdobbins at arbor.net Thu Oct 9 17:04:36 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 00:04:36 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> <1183F513-5ECB-48B9-A06B-18572D3EB73B@arbor.net> Message-ID: On Oct 9, 2014, at 11:31 PM, Owen DeLong wrote: > Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. Various controlled compounds have been chemically tagged for years. NFC or something similar is the logical next step (it also holds a lot of promise and implications for supply-chains in general, physical security applications, transportation, etc.). > I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Concur, but my guess is that they will be essentially superimposed, without any increase in hierarchy - in fact, quite the opposite. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From faisal at snappytelecom.net Thu Oct 9 17:15:01 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 17:15:01 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <5E33293C-2094-4779-B1DF-5FC89B07B7E5@delong.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <4EEF3EDC-BE36-43BD-B726-1B4E23B0C9C7@consultant.com> <1890137137.134876.1412865099546.JavaMail.zimbra@snappytelecom.net> <5E33293C-2094-4779-B1DF-5FC89B07B7E5@delong.com> Message-ID: <1398956912.136866.1412874901494.JavaMail.zimbra@snappytelecom.net> > > Question: Should we be asking ARIN for another /32 so that each network > > has it's own /32 or should be break out the /32 into /36 and use these in > > each of the geographies ? > > Depends on your needs… Either is a viable solution, depending on your > circumstances. ARIN has an MDN policy which would facilitate your > acquisition of a second /32. > Thank you Owen, just got off the phone with ARIN, it should be a fairly simple process for us, and we will follow the advice of using a /32 for each geographical location. The overall discussion has been a very interesting one, and it would appear that the majority of the forward looking opinion is to allocate /48 to customers, and don't do any smaller subnet allocation. We will take this advice and re-evaluate our policies. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Owen DeLong" > To: "Faisal Imtiaz" > Cc: "William Herrin" , nanog at nanog.org > Sent: Thursday, October 9, 2014 12:20:14 PM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > > On Oct 9, 2014, at 7:31 AM, Faisal Imtiaz wrote: > > >>> Selection of a default prefix is easy. Here are the steps. > >>> > >>> 4. Keeping in mind > >>> > >>> 4.1 Prefixes longer than somewhere around /48 to /56 may be > >>> excluded from the global routing table > >> > >> 4.1a Prefix cutouts of any size (including /48) from inside your /32 > >> or larger block may be excluded from the global routing table. Folks > >> who are multihomed and thus need to advertise their own block with BGP > >> should be referred to ARIN for a direct assignment. Folks who aren't > >> multihomed, well, until given evidence otherwise I claim there are no > >> single-homed entities who will use 65,000 LANs, let alone more. > > ============================================= > > > > This brings up another interesting question... > > > > We operate Two separate networks in two geographical locations (Two ASN), > > we have a single /32 allocation from ARIN. > > > > Question: Should we be asking ARIN for another /32 so that each network > > has it's own /32 or should be break out the /32 into /36 and use these in > > each of the geographies ? > > Depends on your needs… Either is a viable solution, depending on your > circumstances. ARIN has an MDN policy which would facilitate your > acquisition of a second /32. > > Owen > > From ryan.landry at gmail.com Thu Oct 9 17:35:17 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 9 Oct 2014 10:35:17 -0700 Subject: another cogent oddity Message-ID: you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date. also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings. from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; } all of it is coming in from cogent: COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0 i shifted all traffic to XO just to make sure. the XO counter doesn't budge. seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not. am i odd to think that this is... odd? i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side. show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4; ryan From faisal at snappytelecom.net Thu Oct 9 17:35:55 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Oct 2014 17:35:55 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: <789900572.137019.1412876155538.JavaMail.zimbra@snappytelecom.net> > Sixty replies and no one linked to the BCOP? > Is there a reason we are ignoring it? > > http://bcop.nanog.org/index.php/IPv6_Subnetting Speaking for myself, I did review that doc, and had some confusion about allocating /64 to Resi-Subscribers. However the broader discussion seems to evolved into a /48 vs /56 discussion, and looks like there is a decent compelling case being made for /48 and not to bother with /56's ... :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Richard Hicks" > To: nanog at nanog.org > Sent: Thursday, October 9, 2014 12:29:21 PM > Subject: Re: IPv6 Default Allocation - What size allocation are you giving out > > Sixty replies and no one linked to the BCOP? > Is there a reason we are ignoring it? > > http://bcop.nanog.org/index.php/IPv6_Subnetting > > As we recently discovered ARIN is handing out IPv6 > allocations on nibble boundaries. > > Either a /32 or /28 for service providers. A justification and > utilization plan is need to get a /28. It is also double the cost > per year. > > > On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong wrote: > > > > > On Oct 9, 2014, at 7:22 AM, Daniel Corbe wrote: > > > > > > > > Mark Andrews writes: > > > > > >> In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes: > > >>> makes more sense to hand out /48s imho. theres only a mere 65k /48s per > > >>> /32 (or something like that), though. > > >> > > >> A /32 is the minimum allocation to a ISP. If you have more customers > > >> or will have more customers request a bigger block from the RIRs. > > >> > > >> Mark > > > > > > Has anyone successfully gotten a RIR to assign anything bigger than a > > > /32? I seem to recall in recent history someone tried to obtain a /31 > > > through ARIN and got smacked down. > > > > I think I answered this before you asked it, but yes,easily on multiple > > occasions. The largest two allocations I have worked on were /24s, but I’m > > sure > > those are not ARIN’s largest allocations. > > > > > Even if you're assigning a /56 to every end user, that's still on the > > > order of 16 million allocations. I can't imagine anyone but the truly > > > behemoth access network operators being able to justify a larger > > > allocation with a straight face. > > > > You should, however, be assigning a /48 to every end user and that’s only > > 65,536 allocations. > > > > Further, you want to be able to aggregate at least one level in your > > network, > > so you may not be able to get anything close to 100% efficiency in that > > distribution. > > > > ARIN policy, for example, defines what is known as a Provider Allocation > > Unit (PAU). > > > > Your PAU is the smallest allocation you give to your customers, so if > > you’re > > giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then > > your PAU is /56. As such, you’re better off to give /48s to everyone > > because > > that sets your PAU at /48. > > > > All of your utilization is measured in terms of PAUs. > > > > You then pick an aggregation level in your network to use as your “serving > > center” > > definition. It could be the POP, or some higher level of aggregation > > containing > > multiple POPs. > > > > Look at the number of end sites served by the largest of those “serving > > centers” > > and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, > > 65536) > > such that the number of end sites is not more than 75% of the chosen poser > > of 16. > > > > Then take the number of “serving centers” you expect to have in ~5 years > > (though > > the exact forward looking time is not actually specified in policy) and > > round that > > up to a nibble boundary as well. > > > > That is the size of allocation you can get from ARIN. > > > > So, for example, if you have 800,000 end-sites served from your largest > > POP and > > you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 > > bits) > > and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up > > needing 36 bits. If your PAU is /48, you would apply for and receive a /12. > > > > Obviously this is an unusually large example. > > > > At a more realistic large ISP scale, let’s say you’ve got 5,000,000 > > subscribers in > > your largest serving center, but only 25 serving centers. > > > > This would, again, round up to 16,777,216 (24 bits) subscribers per > > serving center. > > But your 25 serving centers would round up to 256 (8 bits). That’s 32 > > bits, so instead > > of a /12, you’d get a /16. > > > > > > I hope that clarifies things for people. > > > > Owen > > > > > > > From jvanoppen at spectrumnet.us Thu Oct 9 17:39:18 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 9 Oct 2014 17:39:18 +0000 Subject: another cogent oddity In-Reply-To: References: Message-ID: cogent is well known not to filter in any useful way... in terms of sources that should not be there, we see the same thing (or did the last time I looked). John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 ________________________________________ From: NANOG [nanog-bounces+jvanoppen=spectrumnet.us at nanog.org] on behalf of ryanL [ryan.landry at gmail.com] Sent: Thursday, October 09, 2014 10:35 AM To: North American Network Operators Group Subject: another cogent oddity you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date. also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings. from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; } all of it is coming in from cogent: COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0 i shifted all traffic to XO just to make sure. the XO counter doesn't budge. seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not. am i odd to think that this is... odd? i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side. show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4; ryan From bill at herrin.us Thu Oct 9 17:40:48 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 13:40:48 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks wrote: > Sixty replies and no one linked to the BCOP? > Is there a reason we are ignoring it? Hi Richard, It's dated (a *lot* about IPv6 has changed since 2011) and a we've learned enough to know some of the things in there are dubious. For example: "Regardless of the number of hosts on an individual LAN or WAN segment, every multi-access network (non-point-to-point) requires at least one /64 prefix." But using /64s on WAN links invites needless problems with neighbor discovery when an attacker decides to send one ping each to half a million adresses all of which happen to land on that WAN link. WAN links should really use something whose size is much closer to the number of routers on the link, in the same order of magnitude anyway. So /64s for LANs, sure, but size the WAN links small to make them less vulnerable to attack. And: "Only subnet on nibble boundaries" is not reasonable. When I need two LANs in a building I should burn 14 more to get to a nibble boundary? Really? "Only delegate on nibble boundaries" is a more reasonable statement. When you assign addresses to your customer or to a different internal team's control, THAT should be on a nibble boundary for the customer's convenience understanding the written-down version of what network is theirs and for your convenience when it comes time to delegate reverse DNS. Inside your network under control of the same engineers, subnet and route just as you would with IPv4. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From owen at delong.com Thu Oct 9 17:51:14 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 10:51:14 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <1412866047.20084.235.camel@karl> Message-ID: <502BF870-C806-41B4-B01D-735943170339@delong.com> On Oct 9, 2014, at 8:45 AM, TJ wrote: >> On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: >>> Has anyone successfully gotten a RIR to assign anything bigger than a >>> /32? I seem to recall in recent history someone tried to obtain a /31 >>> through ARIN and got smacked down. >> >> > Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD > got the equivalent of a /13. > > Quick looks: > https://www.sixxs.net/tools/grh/dfp/ > http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html > > > /TJ What DoD actually got as AIUI was a slew of allocations throughout a /13, but not an actual /13. Owen From joelja at bogus.com Thu Oct 9 17:55:33 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 09 Oct 2014 10:55:33 -0700 Subject: another cogent oddity In-Reply-To: References: Message-ID: <5436CC15.7020803@bogus.com> On 10/9/14 10:35 AM, ryanL wrote: > you may remember me from the weird cogent route retention / loop > problem i brought up last week. it remains unsolved by cogent to date. > > also remembering i'm a relatively new cogent customer, i recently > noticed some packets floating into my network that had cos and ipp > markings on them. i figured i'd try to find where they were coming > from, so i crafted up something like this and placed it inbound on my > two transits (cogent and xo), excluding network control markings. > > from { > dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 > af43 cs1 cs2 cs3 cs4 cs5 ef ]; > precedence [ 1 2 3 4 5 ]; > } > > all of it is coming in from cogent: > > COGENT-NOT-BE -> 4217788987 > XO-NOT-BE -> 0 > > i shifted all traffic to XO just to make sure. the XO counter doesn't budge. > > seems like one transit is remarking everything to best effort before > sending to me (which is preferred), and the other is not. > > am i odd to think that this is... odd? It's not that uncommon, but it's one of the reasons to sanitize on ingress if you don't want to see that (and absolutely if you're reusing them). > i also get a remarkable amount of hits against these destinations > coming in on the cogent side, whereas i get none on the XO side. > > show policy-options prefix-list PUBLIC-BAD-NETS > 10.0.0.0/8; > 169.254.0.0/16; > 172.16.0.0/12; > 192.168.0.0/16; > 224.0.0.0/4; you can add 100.64.0.0/10 to that list. ;) > ryan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From richard.hicks at gmail.com Thu Oct 9 17:55:42 2014 From: richard.hicks at gmail.com (Richard Hicks) Date: Thu, 9 Oct 2014 10:55:42 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On Thu, Oct 9, 2014 at 10:40 AM, William Herrin wrote: > On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks > wrote: > > Sixty replies and no one linked to the BCOP? > > Is there a reason we are ignoring it? > > Hi Richard, > > It's dated (a *lot* about IPv6 has changed since 2011) and a we've > learned enough to know some of the things in there are dubious. For > example: > > "Regardless of the number of hosts on an individual LAN or WAN > segment, every multi-access network (non-point-to-point) requires at > least one /64 prefix." > > But using /64s on WAN links invites needless problems with neighbor > discovery when an attacker decides to send one ping each to half a > million adresses all of which happen to land on that WAN link. WAN > links should really use something whose size is much closer to the > number of routers on the link, in the same order of magnitude anyway. > So /64s for LANs, sure, but size the WAN links small to make them less > vulnerable to attack. > The BCOP specfically addresses this in 4b: " *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127*" > And: > > "Only subnet on nibble boundaries" is not reasonable. When I need two > LANs in a building I should burn 14 more to get to a nibble boundary? > Really? > > "Only delegate on nibble boundaries" is a more reasonable statement. > When you assign addresses to your customer or to a different internal > team's control, THAT should be on a nibble boundary for the customer's > convenience understanding the written-down version of what network is > theirs and for your convenience when it comes time to delegate reverse > DNS. > > Inside your network under control of the same engineers, subnet and > route just as you would with IPv4. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From bill at herrin.us Thu Oct 9 18:06:48 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 14:06:48 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On Thu, Oct 9, 2014 at 1:55 PM, Richard Hicks wrote: > On Thu, Oct 9, 2014 at 10:40 AM, William Herrin wrote: >> "Regardless of the number of hosts on an individual LAN or WAN >> segment, every multi-access network (non-point-to-point) requires at >> least one /64 prefix." >> >> But using /64s on WAN links invites needless problems with neighbor >> discovery when an attacker decides to send one ping each to half a >> million adresses all of which happen to land on that WAN link. > > The BCOP specfically addresses this in 4b: > " b. Point-to-point links should be allocated a /64 and configured with a > /126 or /127" It says, effectively, that a WAN link involving 3 or 4 routers (a common redundancy design) should use a /64. I think that's nuts. It creates a needlessly wide attack surface. Use a /124 for that. And if our subnets should be on nibble boundaries, /126 and /127 on ptp links aren't so wise either. Use a /124 for that too. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From ryan.landry at gmail.com Thu Oct 9 18:23:17 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 9 Oct 2014 11:23:17 -0700 Subject: another cogent oddity In-Reply-To: <5436CC15.7020803@bogus.com> References: <5436CC15.7020803@bogus.com> Message-ID: i retract the blurb about the bad destinations coming in from cogent, as that obviously doesn't make a lot of sense. the spoofed traffic is actually arriving on my connection into an ix fabric. thx to john frazier for tickling my brain on that one. the upped markings, however, are definitely coming in from cogent. From owen at delong.com Thu Oct 9 18:21:51 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 11:21:51 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <527DE923-54F7-4F13-843E-1B21AB75E2D8@delong.com> <1183F513-5ECB-48B9-A06B-18572D3EB73B@arbor.net> Message-ID: <25BAF86B-54D3-45A4-891E-8162E264418D@delong.com> On Oct 9, 2014, at 10:04 AM, Roland Dobbins wrote: > > On Oct 9, 2014, at 11:31 PM, Owen DeLong wrote: > >> Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. > > Various controlled compounds have been chemically tagged for years. NFC or something similar is the logical next step (it also holds a lot of promise and implications for supply-chains in general, physical security applications, transportation, etc.). But those chemical tags are generally multiple, not single molecules. NFC still requires something with a unique radiographic property, so not likely in a single molecule. >> I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. > > Concur, but my guess is that they will be essentially superimposed, without any increase in hierarchy - in fact, quite the opposite. Indeed, I think we will end up agreeing to disagree about this, but it will be interesting to see what happens over years to come. I suspect that the answer to which way this goes will be somewhat context sensitive. In some cases, hierarchies will be collapsed. In others, they will expand. Owen From baldur.norddahl at gmail.com Thu Oct 9 18:34:14 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 20:34:14 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On 9 October 2014 19:55, Richard Hicks wrote: > The BCOP specfically addresses this in 4b: > " *b. Point-to-point links should be allocated a /64 and configured with a > /126 or /127*" > Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur From owen at delong.com Thu Oct 9 18:34:40 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 11:34:40 -0700 Subject: Marriott wifi blocking In-Reply-To: <20141005231312.GA18326@panix.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: On Oct 5, 2014, at 4:13 PM, Brett Frankenberger wrote: > On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: >> >>> There's a lot of amateur lawyering ogain on in this thread, in an area >>> where there's a lot of ambiguity. We don't even know for sure that >>> what Marriott did is illegal -- all we know is that the FCC asserted it >>> was and Mariott decided to settle rather than litigate the matter. And >>> that was an extreme case -- Marriott was making transmissions for the >>> *sole purpose of preventing others from using the spectrum*. >> >> I don't see a lot of ambiguity in a plain text reading of part 15. >> Could you please read part 15 and tell me what you think is >> ambiguous? > > Marriott was actually accused of violating 47 USC 333: > No person shall willfully or maliciously interfere with or cause > interference to any radio communications of any station licensed or > authorized by or under this chapter or operated by the United States > Government. > > In cases like the Marriott case, where the sole purpose of the > transmission is to interfere with other usage of the transmission, > there's not much ambiguity. But other cases aren't clear from the > text. > > For example, you've asserted that if I've been using "ABCD" as my SSID > for two years, and then I move, and my new neighbor is already using > that, that I have to change. But that if, instead of duplicating my > new neighbor's pre-existing SSID, I operate with a different SSID but > on the same channel, I don't have to change. I'm not saying your > position is wrong, but it's certainly not clear from the text above > that that's where the line is. That's what I meant by ambiguity. True, but if you read the rest of Part 15, you’ll also find these gems: (From http://www.ecfr.gov/cgi-bin/text-idx?node=47:1.0.1.1.16) §15.3 Definitions. ... (m) Harmful interference. Any emission, radiation or induction that endangers the functioning of a radio navigation service or of other safety services or seriously degrades, obstructs or repeatedly interrupts a radiocommunications service operating in accordance with this chapter. §15.5 General conditions of operation. (a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, or, for power line carrier systems, on the basis of prior notification of use pursuant to §90.35(g) of this chapter. (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. (d) Intentional radiators that produce Class B emissions (damped wave) are prohibited. [54 FR 17714, Apr. 25, 1989, as amended at 75 FR 63031, Oct. 13, 2010] It seems to me that if you deploy something new in such a way that it causes harmful interference to an operating service, you’ve run afoul of 15.5 as defined in 15.3. > > (What's your position on a case where someone puts up, say, a > continuous carrier point-to-point system on the same channel as an > existing WiFi system that is now rendered useless by the p-to-p system > that won't share the spectrum? Illegal or Legal? And do you think the > text above is unambiguous on that point?) > > -- Brett From bill at herrin.us Thu Oct 9 18:42:21 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 14:42:21 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On Thu, Oct 9, 2014 at 2:34 PM, Baldur Norddahl wrote: > Why do people assign addresses to point-to-point links at all? It makes remote detection of carrier on the interface as simple as "ping" -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From bill at herrin.us Thu Oct 9 18:54:32 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 14:54:32 -0400 Subject: Marriott wifi blocking In-Reply-To: <20141005231312.GA18326@panix.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: On Sun, Oct 5, 2014 at 7:13 PM, Brett Frankenberger wrote: > (What's your position on a case where someone puts up, say, a > continuous carrier point-to-point system on the same channel as an > existing WiFi system that is now rendered useless by the p-to-p system > that won't share the spectrum? Illegal or Legal? And do you think the > text above is unambiguous on that point?) Not how 802.11 works. Put up another transmitter on a different SSID and it raises the noise floor for everybody. It doesn't render the frequency useless. Remember, we got 2.4ghz in the first place because the huge signal interference from microwave ovens and -rain- had already rendered it useless. Until spread spectrum came along. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From rwebb at ropeguru.com Thu Oct 9 19:04:42 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 09 Oct 2014 15:04:42 -0400 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: So is the main factor here in all the FCC verbage become that the WiFi spectrum is NOT a licensed band and therefore does not fall under the interference regulations unless they are interfering with a licensed band? I think the first sentence below says a lot to that. The basic premise of all Part 15 unlicensed operation is that unlicensed devices cannot cause interference to licensed operations nor are they protected from any interference received. The operational parameters for unlicensed operation are set forth in Section 15.5 of the rules, as follows: (a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. http://transition.fcc.gov/sptf/files/E&UWGFinalReport.doc On Thu, 9 Oct 2014 11:34:40 -0700 Owen DeLong wrote: > > On Oct 5, 2014, at 4:13 PM, Brett Frankenberger > wrote: > >> On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: >>> >>>> There's a lot of amateur lawyering ogain on in this thread, in an >>>>area >>>> where there's a lot of ambiguity. We don't even know for sure that >>>> what Marriott did is illegal -- all we know is that the FCC asserted >>>>it >>>> was and Mariott decided to settle rather than litigate the matter. >>>> And >>>> that was an extreme case -- Marriott was making transmissions for >>>>the >>>> *sole purpose of preventing others from using the spectrum*. >>> >>> I don't see a lot of ambiguity in a plain text reading of part 15. >>> Could you please read part 15 and tell me what you think is >>> ambiguous? >> >> Marriott was actually accused of violating 47 USC 333: >> No person shall willfully or maliciously interfere with or cause >> interference to any radio communications of any station licensed >>or >> authorized by or under this chapter or operated by the United >>States >> Government. >> >> In cases like the Marriott case, where the sole purpose of the >> transmission is to interfere with other usage of the transmission, >> there's not much ambiguity. But other cases aren't clear from the >> text. >> >> For example, you've asserted that if I've been using "ABCD" as my >>SSID >> for two years, and then I move, and my new neighbor is already using >> that, that I have to change. But that if, instead of duplicating my >> new neighbor's pre-existing SSID, I operate with a different SSID >>but >> on the same channel, I don't have to change. I'm not saying your >> position is wrong, but it's certainly not clear from the text above >> that that's where the line is. That's what I meant by ambiguity. > > True, but if you read the rest of Part 15, you’ll also find these >gems: > > (From http://www.ecfr.gov/cgi-bin/text-idx?node=47:1.0.1.1.16) > §15.3 Definitions. > ... > (m) Harmful interference. Any emission, radiation or induction that >endangers the functioning of a radio navigation service or of other >safety services or seriously degrades, obstructs or repeatedly >interrupts a radiocommunications service operating in accordance with >this chapter. > > > §15.5 General conditions of operation. > > (a) Persons operating intentional or unintentional radiators shall >not be deemed to have any vested or recognizable right to continued >use of any given frequency by virtue of prior registration or >certification of equipment, or, for power line carrier systems, on >the basis of prior notification of use pursuant to §90.35(g) of this >chapter. > > (b) Operation of an intentional, unintentional, or incidental >radiator is subject to the conditions that no harmful interference is >caused and that interference must be accepted that may be caused by >the operation of an authorized radio station, by another intentional >or unintentional radiator, by industrial, scientific and medical >(ISM) equipment, or by an incidental radiator. > > (c) The operator of a radio frequency device shall be required to >cease operating the device upon notification by a Commission >representative that the device is causing harmful interference. >Operation shall not resume until the condition causing the harmful >interference has been corrected. > > (d) Intentional radiators that produce Class B emissions (damped >wave) are prohibited. > > [54 FR 17714, Apr. 25, 1989, as amended at 75 FR 63031, Oct. 13, >2010] > > > It seems to me that if you deploy something new in such a way that >it causes harmful interference to an operating service, you’ve run >afoul of 15.5 as defined in 15.3. > > >> >> (What's your position on a case where someone puts up, say, a >> continuous carrier point-to-point system on the same channel as an >> existing WiFi system that is now rendered useless by the p-to-p >>system >> that won't share the spectrum? Illegal or Legal? And do you think >>the >> text above is unambiguous on that point?) >> >> -- Brett > From SNaslund at medline.com Thu Oct 9 19:41:31 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Oct 2014 19:41:31 +0000 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com> I don't read it that way at all. It is illegal to intentionally interfere (meaning intending to prevent others from effectively using the resource) with any licensed or unlicensed frequency. That is long standing law. It says in (b) that you must accept interference caused by operation of an AUTHORIZED station or intentional or unintentional radiator (like a microwave oven which serves a purpose, or a amateur radio operator messing up your TV once in awhile (as long as he is operating within his license), not a jammer that has no purpose other than to prevent others from using an authorized spectrum). To me that looks like as long as the other guy is using the frequency band in an authorized manner (i.e. not purposely stopping others from using it, but using it for their own authorized purpose) you have to deal with it. So another guy using your channel (which is not really "yours") for his network would be fine but if he is purposely camped on your SSID and deauthing your clients is not using it legally. As far as who owns an SSID, I don't think there is any law on that unless it is a trademarked name but the FCC rules in general give the incumbent user the right of way. If two licensed systems interfere with each other (common in licensed microwave), the older system usually gets to stay and the new system has to change. I think they would be unlikely to get involved in the whole SSID dispute (because they don't regulate SSIDs or the 802.11 standards) they would most likely tell you it's a civil matter and walk away. Now, if you are using someone else's SSID for the purpose of intruding, you are violating Part 15 because that is not authorized spectrum usage. That they will probably address. I don't think the FCC would classify a wifi router operating normally as interference, but a device purposely bouncing clients off of the clients own network would be. I have worked with them a lot as a frequency coordinator with the Air Force and find that the enforcement guys have quite a bit of common sense and apply a good measure of it to deciding what to enforce or not enforce. My guess (you would have to ask them) is that an entity defending their SSID from unauthorized access is an acceptable security feature but someone using a different SSID and not trying to connect to the entities network should not be active messed with. If my SSID is there first and you show up and try to kick my clients off so you can use it, you will appear to be the aggressor and I will appear to be the defender. In the same way that it is not legal for me to punch you in the face unless of course you punched me in the face first and I'm defending myself. It gets messy when you get into the cellular world. I don't think you would be within the law jamming or blocking cell phones even within your building (even though the government is known to do so). You could however have a policy that prevents people from bringing a cell phone into your building. The public has no right of access to your property so you are free to make rules about what can and can't come within your building. I do know that the areas I have worked in that had cellular jammers for security purposes are already areas where they are prohibited by regulation. National security trumps a lot of other laws. Remember, a lot of law is about intent and it is clear that the intent of this law is to allow everyone access to use the ISM spectrum for useful purposes and to prevent people from interfering with your right to do so. Any case has to take that into account. In the Marriott case, I think it would be a tough argument for them to show anything other than stopping people from using anything other than their wifi service when it is clear that someone could use their own network services without causing undue harm to Marriott. In my own environment, there are tons of clients running around with their devices wifi tethered to phones and searching for their home wifi networks. As long as they stay off my SSIDs, they will not be harmed. If they try to connect to my SSID they better authenticate or they get denied. If they keep trying, they will get ACL'd out. If you set up an AP and try to plug it into my wired infrastructure that's when the active stuff comes into effect because you have no right to add a device to my wired network. Steve Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Robert Webb >Sent: Thursday, October 09, 2014 2:05 PM >To: Owen DeLong; Brett Frankenberger >Cc: nanog at nanog.org; Brandon Ross >Subject: Re: Marriott wifi blocking > >So is the main factor here in all the FCC verbage become that the WiFi spectrum is NOT a licensed band and therefore does not fall under the interference regulations unless they are interfering with a licensed band? > >I think the first sentence below says a lot to that. > >The basic premise of all Part 15 unlicensed operation is that unlicensed devices cannot cause interference to licensed operations nor are they protected from any interference received. The operational parameters for unlicensed >operation are set forth in Section 15.5 of the rules, as follows: >(a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, >(b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized >radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. >(c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. > Operation shall not resume until the condition causing the harmful interference has been corrected. From owen at delong.com Thu Oct 9 20:01:06 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 13:01:06 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On Oct 9, 2014, at 11:34 AM, Baldur Norddahl wrote: > On 9 October 2014 19:55, Richard Hicks wrote: > >> The BCOP specfically addresses this in 4b: >> " *b. Point-to-point links should be allocated a /64 and configured with a >> /126 or /127*" >> > > Why do people assign addresses to point-to-point links at all? You can just > use a host /128 route to the loopback address of the peer. Saves you the > hassle of coming up with new addresses for every link. Same trick works for > IPv4 too. > > Regards, > > Baldur And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. There are a number of good technical reasons to want distinct addresses on point to point links. Owen From baldur.norddahl at gmail.com Thu Oct 9 20:25:10 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 22:25:10 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: On 9 October 2014 22:01, Owen DeLong wrote: > > Why do people assign addresses to point-to-point links at all? You can > just > > use a host /128 route to the loopback address of the peer. Saves you the > > hassle of coming up with new addresses for every link. Same trick works > for > > IPv4 too. > > > > Regards, > > > > Baldur > > > > And it makes your trace-routes across parallel links oh so easy to > identify which of them is at fault for the packet loss, too. > > > There are a ton of other technologies with the same problem. Do you never use link aggregation? My "parallel links" are all link aggregations, so I would not have a way to identify links by traceroute anyway. There are a number of good technical reasons to want distinct addresses on > point to point links. > I am sure there are. Tell me about them. I am not disputing that there are many reasons to sometimes use link addresses. My question is why do you do it by default? So far we have heard two arguments: 1) You can ping the link address. I assume his equipment will down the address if the link is down. My equipment does not do this, I can ping it as long it is administrative up no matter link status. So this test is useless to me. I am monitoring links by SNMP anyway. 2) Parallel links. I don't have many of those, and the ones I have are link aggregations. MPLS interferes with this too. On the other hand not using link addresses has some advantages: 1) You don't need to assign and document them. 2) It is easy to think about: Router A talks to Router B on link AB. Every router has only one address so you don't need to remember which address to use. 3) You avoid having a lot of addresses configured on your router. 4) You are immune to all the NDP attacks. 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs /124 vs /64. The correct answer is clearly use /128 :-). Regards, Baldur From owen at delong.com Thu Oct 9 20:27:21 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 13:27:21 -0700 Subject: Marriott wifi blocking In-Reply-To: <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com> Message-ID: On Oct 9, 2014, at 12:41 PM, Naslund, Steve wrote: > I don't read it that way at all. It is illegal to intentionally interfere (meaning intending to prevent others from effectively using the resource) with any licensed or unlicensed frequency. That is long standing law. Indeed… this is 47CFR333. It’s not limited to Part 15 (47CFR15). > It says in (b) that you must accept interference caused by operation of an AUTHORIZED station or intentional or unintentional radiator (like a microwave oven which serves a purpose, or a amateur radio operator messing up your TV once in awhile (as long as he is operating within his license), not a jammer that has no purpose other than to prevent others from using an authorized spectrum). To me that looks like as long as the other guy is using the frequency band in an authorized manner (i.e. not purposely stopping others from using it, but using it for their own authorized purpose) you have to deal with it. So another guy using your channel (which is not really "yours") for his network would be fine but if he is purposely camped on your SSID and deauthing your clients is not using it legally. Now you’re talking about 47CFR15 (Part 15) and more specifically about 15.5(b). Otherwise, yes, you are exactly right. > As far as who owns an SSID, I don't think there is any law on that unless it is a trademarked name but the FCC rules in general give the incumbent user the right of way. If two licensed systems interfere with each other (common in licensed microwave), the older system usually gets to stay and the new system has to change. I think they would be unlikely to get involved in the whole SSID dispute (because they don't regulate SSIDs or the 802.11 standards) they would most likely tell you it's a civil matter and walk away. Now, if you are using someone else's SSID for the purpose of intruding, you are violating Part 15 because that is not authorized spectrum usage. That they will probably address. I don’t believe that there is any such thing as “Owning an SSID”. One might be able to try and claim that ownership of a *mark (where * = one or more of {trade,service,etc.}) extends to use of that name in an SSID, but generally speaking, I think the most likely outcome would be to treat an SSID as an address and declare that addresses are not subject to those limitations. > I don't think the FCC would classify a wifi router operating normally as interference, but a device purposely bouncing clients off of the clients own network would be. I have worked with them a lot as a frequency coordinator with the Air Force and find that the enforcement guys have quite a bit of common sense and apply a good measure of it to deciding what to enforce or not enforce. My guess (you would have to ask them) is that an entity defending their SSID from unauthorized access is an acceptable security feature but someone using a different SSID and not trying to connect to the entities network should not be active messed with. If my SSID is there first and you show up and try to kick my clients off so you can use it, you will appear to be the aggressor and I will appear to be the defender. In the same way that it is not legal for me to punch you in the face unless of course you punched me in the face first and I'm defending myself. I think the FCC would, likely, classify two neighbors in adjacent apartments arguing over the same SSID and unwilling to move either one of them would likely both get told to cease and desist until they picked different SSIDs, though it’s hard for me to believe that this would get elevated to the FCC very often. More often one person or the other will change their SSID and move on. > It gets messy when you get into the cellular world. I don't think you would be within the law jamming or blocking cell phones even within your building (even though the government is known to do so). You could however have a policy that prevents people from bringing a cell phone into your building. The public has no right of access to your property so you are free to make rules about what can and can't come within your building. I do know that the areas I have worked in that had cellular jammers for security purposes are already areas where they are prohibited by regulation. National security trumps a lot of other laws. In fact, movie theaters tried this briefly and got a pretty strong smack from the FCC as a result. http://www.fcc.gov/encyclopedia/cell-phone-and-gps-jamming However, that’s not what was being discussed in the BART example. In this case, repeaters with unclear ownership operated by cellular providers were shut down by BART authorities to try and disrupt a protest. That’s not active jamming, so most likely, not an FCC issue. There are other areas of concern, however, such as 1st amendment violations, abuse of authority, potential civil liability if anyone was unable to reach 911 in an expected manner, etc. Owen From rdobbins at arbor.net Thu Oct 9 20:32:03 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 03:32:03 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> On Oct 10, 2014, at 3:25 AM, Baldur Norddahl wrote: > I am sure there are. Tell me about them. This issue has been discussed on all the various operational lists many, many times over the years. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From owen at delong.com Thu Oct 9 20:38:00 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Oct 2014 13:38:00 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: <526C69C1-C1FF-4071-AA61-C6A5C08A3D3E@delong.com> On Oct 9, 2014, at 1:25 PM, Baldur Norddahl wrote: > On 9 October 2014 22:01, Owen DeLong wrote: > >>> Why do people assign addresses to point-to-point links at all? You can >> just >>> use a host /128 route to the loopback address of the peer. Saves you the >>> hassle of coming up with new addresses for every link. Same trick works >> for >>> IPv4 too. >>> >>> Regards, >>> >>> Baldur >> >> >> >> And it makes your trace-routes across parallel links oh so easy to >> identify which of them is at fault for the packet loss, too. >> >> >> > > There are a ton of other technologies with the same problem. Do you never > use link aggregation? My "parallel links" are all link aggregations, so I > would not have a way to identify links by traceroute anyway. Your design problems don’t have to be mine. Just because you have created that problem through another mechanism doesn’t pose a reason anyone else should accept the same problem in a different circumstance. > There are a number of good technical reasons to want distinct addresses on >> point to point links. >> > > I am sure there are. Tell me about them. I gave you one. You decided to dismiss it on the basis of “it wouldn’t help me anyway because I use this other thing that is broken that way regardless.” Some others (not a conclusive list by any means): Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. Clarity is almost always an advantage over obscurity when one is troubleshooting something. Being able to ping the link address is useful for troubleshooting. Being able to source packets from a particular link address can be useful for troubleshooting. > I am not disputing that there are many reasons to sometimes use link > addresses. My question is why do you do it by default? > > So far we have heard two arguments: > > 1) You can ping the link address. I assume his equipment will down the > address if the link is down. My equipment does not do this, I can ping it > as long it is administrative up no matter link status. So this test is > useless to me. I am monitoring links by SNMP anyway. I can’t help that your equipment is ill-behaved at best. Perhaps you should consider alternatives. I certainly don’t think that designing everyone else’s network to the level of brokenness in your particular environment is particularly valid. > > 2) Parallel links. I don't have many of those, and the ones I have are link > aggregations. MPLS interferes with this too. > > On the other hand not using link addresses has some advantages: > > 1) You don't need to assign and document them. Sure you do, it’s just harder. You’re now using essentially an “unnumbered interface” which needs to be documented as such so that people know that when a given loopback shows up, it’s not a unique identifier, but ambiguous across several interfaces. > 2) It is easy to think about: Router A talks to Router B on link AB. Every > router has only one address so you don't need to remember which address to > use. I don’t have to remember which address to use normally. This is not an advantage. I can always use the loopback address to talk to a router if my environment is correctly functioning. If it is not, removing the ambiguity of unnumbered link addresses is more helpful than being able to use one address for each router while unable to know how traffic is actually flowing as a result. > 3) You avoid having a lot of addresses configured on your router. I don’t see this as an advantage. For a number of reasons (some of which I have expressed above) it is, in fact, a disadvantage. > 4) You are immune to all the NDP attacks. No you aren’t. You just change the nature of those attacks. > 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs > /124 vs /64. The correct answer is clearly use /128 :-). Except that it’s clearly an incorrect answer, IMHO. Owen From baldur.norddahl at gmail.com Thu Oct 9 20:42:52 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 22:42:52 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: On 9 October 2014 22:32, Roland Dobbins wrote: > > On Oct 10, 2014, at 3:25 AM, Baldur Norddahl > wrote: > > > I am sure there are. Tell me about them. > > This issue has been discussed on all the various operational lists many, > many times over the years. > > > The linked document talks about issues with using private IP addresses. I am not suggesting that you do that. I am suggesting that you use _no_ IP addresses on the links. Generally the devices will use the loopback IP, which will be public, for your traceroutes and for ICMP. None of the issues in RFC 6752 are applicable to the concept of using host routes to peer loopback address instead of assigning link specific addressing. Regards, Baldur From bill at herrin.us Thu Oct 9 20:49:01 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 16:49:01 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: On Thu, Oct 9, 2014 at 4:32 PM, Roland Dobbins wrote: > > On Oct 10, 2014, at 3:25 AM, Baldur Norddahl wrote: > >> I am sure there are. Tell me about them. > > This issue has been discussed on all the various operational lists many, many times over the years. > > Hi Roland, 6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. Baldur want's to know: why not just use one public IP address per router and use it on all interfaces? Baldur, one IP per router can work just as well as one subnet per interface. But there are some gotchas: Your router has one IP. Your customer has a subnet. Do you add an extra deaggregated single IP to your routing table for his router? There are more routers than links, so if you assign subnets to routers instead of links you'll have to carry more routes. If you borrow the customer LAN-side IP for the WAN side you'll get grief when his equipment is one of those that doesn't respond if the LAN-side interface is down (e.g. Cisco). That gets kind of nasty when troubleshooting and remediating problems. And of course the more knowledge you can gather from diagnostic tools like traceroute, the more quickly you can identify the problem when something doesn't work right.. In my own networks... I want to keep as many IPv4 addresses as I can, so my router interfaces borrow their ip from loop0. In IPv6 where I can have a functionally infinite number of /124's I want to put one on each interface and gain the mild extra benefit. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From baldur.norddahl at gmail.com Thu Oct 9 20:53:50 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 22:53:50 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <526C69C1-C1FF-4071-AA61-C6A5C08A3D3E@delong.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <526C69C1-C1FF-4071-AA61-C6A5C08A3D3E@delong.com> Message-ID: I am sorry if I stepped on something sore. I am not dismissing any arguments, and I am genuinely interested in any advantages and disadvantages to the approach. There is more than one way to design a network and all I am saying is this far it is working great for me. The two disadvantages put forward so far have not been of any consequences in my network. But I am concerned that you say that I am still vulnerable to NDP attacks. Could you elaborate on that please? About loopback not being an unique identifier, please remember that none of the IP addresses on a host is that. An IP address belongs to the host, not the interface. Creating addresses on interfaces is just an alias for creating the same address as loopback and adding a net route on the interface. Don't believe me? Try it out! "I can’t help that your equipment is ill-behaved at best." That is not ill-behaved. It is the correct behavior. Try unplugging the netcable from your computer - you will NOT lose the IP-address unless you have a DHCP daemon that takes it away. Regards, Baldur On 9 October 2014 22:38, Owen DeLong wrote: > > On Oct 9, 2014, at 1:25 PM, Baldur Norddahl > wrote: > > > On 9 October 2014 22:01, Owen DeLong wrote: > > > >>> Why do people assign addresses to point-to-point links at all? You can > >> just > >>> use a host /128 route to the loopback address of the peer. Saves you > the > >>> hassle of coming up with new addresses for every link. Same trick works > >> for > >>> IPv4 too. > >>> > >>> Regards, > >>> > >>> Baldur > >> > >> > >> > >> And it makes your trace-routes across parallel links oh so easy to > >> identify which of them is at fault for the packet loss, too. > >> > >> > >> > > > > There are a ton of other technologies with the same problem. Do you never > > use link aggregation? My "parallel links" are all link aggregations, so I > > would not have a way to identify links by traceroute anyway. > > Your design problems don’t have to be mine. > > Just because you have created that problem through another mechanism > doesn’t pose a reason anyone else should accept the same problem in a > different circumstance. > > > There are a number of good technical reasons to want distinct addresses > on > >> point to point links. > >> > > > > I am sure there are. Tell me about them. > > I gave you one. You decided to dismiss it on the basis of “it wouldn’t > help me anyway because I use this other thing that is broken that way > regardless.” > > Some others (not a conclusive list by any means): > Having public addresses in trace-routes, ideally with good reverse > DNS is actually useful. > Clarity is almost always an advantage over obscurity when one is > troubleshooting something. > Being able to ping the link address is useful for troubleshooting. > Being able to source packets from a particular link address can be > useful for troubleshooting. > > > I am not disputing that there are many reasons to sometimes use link > > addresses. My question is why do you do it by default? > > > > > > So far we have heard two arguments: > > > > 1) You can ping the link address. I assume his equipment will down the > > address if the link is down. My equipment does not do this, I can ping it > > as long it is administrative up no matter link status. So this test is > > useless to me. I am monitoring links by SNMP anyway. > > I can’t help that your equipment is ill-behaved at best. Perhaps you > should consider alternatives. > I certainly don’t think that designing everyone else’s network to the > level of brokenness in your particular environment is particularly valid. > > > > > 2) Parallel links. I don't have many of those, and the ones I have are > link > > aggregations. MPLS interferes with this too. > > > > On the other hand not using link addresses has some advantages: > > > > 1) You don't need to assign and document them. > > Sure you do, it’s just harder. You’re now using essentially an “unnumbered > interface” which needs to be documented as such so that people know that > when a given loopback shows up, it’s not a unique identifier, but ambiguous > across several interfaces. > > > 2) It is easy to think about: Router A talks to Router B on link AB. > Every > > router has only one address so you don't need to remember which address > to > > use. > > I don’t have to remember which address to use normally. This is not an > advantage. > I can always use the loopback address to talk to a router if my > environment is correctly > functioning. If it is not, removing the ambiguity of unnumbered link > addresses is more > helpful than being able to use one address for each router while unable to > know how > traffic is actually flowing as a result. > > > 3) You avoid having a lot of addresses configured on your router. > > I don’t see this as an advantage. For a number of reasons (some of which I > have expressed above) it is, in fact, a disadvantage. > > > 4) You are immune to all the NDP attacks. > > No you aren’t. You just change the nature of those attacks. > > > 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs > > /124 vs /64. The correct answer is clearly use /128 :-). > > Except that it’s clearly an incorrect answer, IMHO. > > Owen > > From drohan at gmail.com Thu Oct 9 20:57:45 2014 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 9 Oct 2014 13:57:45 -0700 Subject: Strategies for migrating lots of customers into L3VPN / route-leaking [x-post from j-nsp] Message-ID: [apologies for the x-post-- I didn't get any responses from the j-nsp list, so I thought I'd try a larger audience- edited to remove some juniper jargon] Hi all, I'm working on virtualizing a regional network with about 500 customer sites into an L3VPN. All of my customer routes (plus our internet routes) currently exist in the global table on our routers. The end-state I’d like to achieve is to have our provider's Internet routes isolated into a VRF and our customers isolated into their own VRF with vrf-import policies leaking the routes between the two. Before someone asks “why?” I’ll just stop that and say that it’s likely that in the near future I’ll have different customer classes demanding different upstream providers on the same physical gear but still wanting the same path/latency to the other customer classes we provide today. So- I’d like to move our customer routes piecemeal into a VRF in as controlled a way as possible without causing network segmentation or having to constrain traffic through specific paths. That way we could move reasonable sections of the network into the L3VPN over a period of a few weeks. My first thought was to set up route leaking between the VRFs and the global table, but looking back at listserv threads as well as Juniper docs, I realize it's not possible to export MP-BGP learned routes into the global table using Juniper rib groups. I'm currently looking into using BGP between logical tunnel interfaces on the global table and a vrf to accomplish the route sharing, and that seems like a good possibility, but I’m curious about a few things: 1) Does anyone run production traffic through logical tunnel interfaces between the global table and routing instances? (we’re using fairly lightly-loaded MX480s) 2) Does any one have a smarter strategy that I could borrow to accomplish this transition? It all feels so kludge-y and brittle. -Dan From chris at in-berlin.de Thu Oct 9 20:58:05 2014 From: chris at in-berlin.de (Christian Seitz) Date: Thu, 09 Oct 2014 22:58:05 +0200 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141008144238.GE10316@Vurt.local> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> Message-ID: <5436F6DD.1080100@in-berlin.de> Hello, Am 08.10.2014 um 16:42 schrieb Job Snijders: >> If you think this is a terrible idea and want to express all that is >> wrong with it, tell me that too, I can take it. I support the RTBH idea. I also set up https://wiki.rtbh.me/ for this some time ago and there is also a discuss mailing list where already 65 people are subscribed. Currently there is not much discussion on the list, but you all can change this ;-) Also there is no other content besides the mailing list in the wiki right now. I have removed it because somebody thought that it may be confusing for some people on the list as he wanted to use it for a general RTBH discussion instead of my project. I will try to restore it in the next days... > Just like chicory, personally I don't like it. Yes, Cymru has build a > reputation as clearing house for redistribution of security related > information. But... (aside from any local safety net filter), it's quite > a leap to allow a single entity to inject blackholes for any prefix. What I do not like at this UTRS idea is that I cannot announce a prefix via BGP. Somebody has to inject it for me. I would like to announce it in real time and not with delay because of manual approval. One problem that I also see here is that this single entity could be forced by someone (eg. government) to blackhole some prefix. If this ever happens such a project will have to be terminated. > There are various flavors at the moment in terms of validation (please > correct me if I am wrong): The Polish blackholing project only allows > blackholes which fall within the set of prefixes which an ASN > originates, the DE-CIX BS service accepts anything that is a subset of > your AS-SET. > > Both approaches have their downsides: you can make any AS or AS-SET a > member of your AS-SET and thereby gain a degree of control on the RTBH > server, and for $500/year you can register any route-object you want in > RADB. Allowing ASN to blackhole a prefix based on AS sets is dangerous from my point of view. In the RIPE database you can add any AS to your AS set without verification. Ok, it doesn't make much difference because most IP transit providers also filter on the AS set, but a worldwide announced /24 prefix is much more visible than a /32 blackhole route that is only announced to the participants. My idea was that an ASN can only announce more specifics prefixes (not just /32) from officially registered routes. Downstream ASN should also be able to define their upstream ASN who may blackhole their prefixes if they do not set up their own session to the RTBH route servers. Most IP transit providers have an RTBH service for their customers that these downstream ASN could use. Usually they do not offer such a service for peers. This is the useful part here. We also had some DDoS attacks via IPv6. I think it's important to also have such a service for IPv6. Starting with IPv4 is ok and better than nothing, but IPv6 should not be on the roadmap for 2018 ;-) > Might I suggest an alternative approach, without central validation or > need for a clearing house: > > IXPs could offer BGP or API triggered ACLs which are inserted into the > peering fabric and only affect the participant's peering port(s). This > way, any blackholing (either correctly applied or malicious) only > affects the initator of that blackhole and nobody else. Advantages are > that aclserver does not require peers to cooperate with each other and > no validation is required. Why is there no validation required when this is done by an IXP? "All peers are my customers and I do trust them"? What about private peerings via PNIs? Regards, Chris -- Individual Network Berlin e.V. : support at in-berlin.de : vorstand at in-berlin.de Tel +49-30-45494343 ::: Fax +49-30-45494344 ::: Web https://www.in-berlin.de/ IN-Berlin e.V. : Christian Seitz (1. Vors.) : Lehrter Str. 53 :: 10557 Berlin Amtsgericht Charlottenburg 95 - VR 15669 Nz ::::::: USt.Ident-Nr. DE188894648 From rdobbins at arbor.net Thu Oct 9 21:08:30 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 04:08:30 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: On Oct 10, 2014, at 3:49 AM, William Herrin wrote: > 6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. I beg to differ, as noted by Owen DeLong in this same thread: On 9 October 2014 22:01, Owen DeLong wrote: > Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. > Clarity is almost always an advantage over obscurity when one is troubleshooting something. > Being able to ping the link address is useful for troubleshooting. > Being able to source packets from a particular link address can be useful for troubleshooting. Several of the very same caveats apply - that's why I cited the informational RFC with regards to private IP addressing, rather than re-typing the same things all over again. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From baldur.norddahl at gmail.com Thu Oct 9 21:13:16 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Oct 2014 23:13:16 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: Hi Bill Thanks for you response. About customer routers: For IPv6 that answer is simple. The customer is using us as default gateway and that always uses the IPv6 link local address. He has no need to know the public IPv6 address of the uplink router, so we don't tell him. The link local address is learned automatically from the RA packets. The customer router needs an IP address. I do that by allocating a small prefix, typically a /120, which covers all the users on the same access switch. The IP, a /128, is assigned by DHCPv6 and he gets his /48 by prefix delegation. There is no way to avoid a route for that /48. This works great with asymmetric bridges (isolated vlans etc). For IPv4 I do have an IP address on the customer facing interface. Typically a /24 for users on the same access switch using MFF (MAC Forced Forwarding). I do wonder if I could get away with using a /32 and push out a host route through DHCP, but I am unsure if clients generally support that. But all this are customer facing interfaces, which do not really qualify for "point to point" links. I might consider adding interface addressing for IPv6, but for me IPv4 was the primary design parameter. Having IPv6 mirror the IPv4 setup means I have to think less about the setup. And we are really constrained to use as few IPv4 addresses as possible. We only got 1024 from RIPE and have to buy any additional at great expense. My colleges wanted to completely drop using public IP addressing in the infrastructure. I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely? Because frankly, that is the alternative. Regards, Baldur On 9 October 2014 22:49, William Herrin wrote: > On Thu, Oct 9, 2014 at 4:32 PM, Roland Dobbins wrote: > > > > On Oct 10, 2014, at 3:25 AM, Baldur Norddahl > wrote: > > > >> I am sure there are. Tell me about them. > > > > This issue has been discussed on all the various operational lists many, > many times over the years. > > > > > > > Hi Roland, > > 6752 isn't germane; it has to do with using private IP addresses on > routers, which borks things up when the router has to generate an ICMP > type 3. Baldur want's to know: why not just use one public IP address > per router and use it on all interfaces? > > Baldur, one IP per router can work just as well as one subnet per > interface. But there are some gotchas: > > Your router has one IP. Your customer has a subnet. Do you add an > extra deaggregated single IP to your routing table for his router? > There are more routers than links, so if you assign subnets to routers > instead of links you'll have to carry more routes. > > If you borrow the customer LAN-side IP for the WAN side you'll get > grief when his equipment is one of those that doesn't respond if the > LAN-side interface is down (e.g. Cisco). That gets kind of nasty when > troubleshooting and remediating problems. > > And of course the more knowledge you can gather from diagnostic tools > like traceroute, the more quickly you can identify the problem when > something doesn't work right.. > > > In my own networks... I want to keep as many IPv4 addresses as I can, > so my router interfaces borrow their ip from loop0. In IPv6 where I > can have a functionally infinite number of /124's I want to put one on > each interface and gain the mild extra benefit. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From rdobbins at arbor.net Thu Oct 9 21:18:33 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 04:18:33 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> On Oct 10, 2014, at 4:13 AM, Baldur Norddahl wrote: > My colleges wanted to completely drop using public IP addressing in the infrastructure. Your colleagues are wrong. Again, see RFC6752. > I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely? This is a false dichotomy. > Because frankly, that is the alternative. It isn't the only alternative. The *optimal* alternative is to use publicly-routable link addresses, and then protect your infrastructure using iACLs, GTSM, CoPP, et. al. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From rdobbins at arbor.net Thu Oct 9 21:18:46 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 04:18:46 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <526C69C1-C1FF-4071-AA61-C6A5C08A3D3E@delong.com> Message-ID: <2F207DFC-EF17-4338-8769-657FEE8EC91C@arbor.net> On Oct 10, 2014, at 3:53 AM, Baldur Norddahl wrote: > I am not dismissing any arguments, and I am genuinely interested in any advantages and disadvantages to the approach. My prediction is that you will remain an advocate of unnumbered links until such time as you have to troubleshoot issues hop-by-hop in a network of any non-trivial size/complexity. Then, your views on this topic will likely change. Many of the same caveats noted in RFC6752 apply to unnumbered interfaces, as well. That's why I cited it. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From job at instituut.net Thu Oct 9 21:19:05 2014 From: job at instituut.net (Job Snijders) Date: Thu, 9 Oct 2014 23:19:05 +0200 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <5436F6DD.1080100@in-berlin.de> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> <5436F6DD.1080100@in-berlin.de> Message-ID: <20141009211905.GZ10316@Vurt.local> Hi Christian, On Thu, Oct 09, 2014 at 10:58:05PM +0200, Christian Seitz wrote: > > > Why is there no validation required when this is done by an IXP? "All > peers are my customers and I do trust them"? What about private > peerings via PNIs? Validation is not required because the requester can only affect his or her own peering ports. Conceptually the IXP participant sets an ACL, just not on their own ingress routerport but on the egress port just across the crossconnect, this prevents congestion of said crossconnect. Modern switching/routing equipment used in IXPs can do far more then mere L2 switching. Lots of chipsets these days allow you to apply combined layer-3 + layer-2 ACLs, an example would be "Discard traffic if (destination IP is A && destination MAC is B)". The blackhole route is announced to a special network component which I dub the "ACL Server". The ACL Server is operated by the IXP (exabgp + customizations?). The ACL Server takes the prefix and associated origin (origin is a static lookup table based on source IP or ASN, IXPs know who their members are) and then inserts a layer3+layer2 ACL into their switching fabric. If the IXP, on every ingress port, have a ACL that says "drop traffic to this IP if the dest MAC address corresponds with the originator of the ACL request", the ddos traffic doesn't even hit the IXPs backbone, and only affects the peering participant who requested the ACL to be inserted. So the blackhole route only lives inside the IXP's switching fabric so to speak, as an ACL only applicable to the participant itself. Regarding implementation: some IXPs might have to screenscrape/expect to apply ACLs on their switches with clogin, others will just convert the announcement and insert flowspec or sdn rules in the fabric. It is the IXP's job to sanitize the ACL trigger in such a way that it only applies to the peering ports of the participant requesting it. I hope this clarifies a bit. Kind regards, Job From bill at herrin.us Thu Oct 9 21:25:00 2014 From: bill at herrin.us (William Herrin) Date: Thu, 9 Oct 2014 17:25:00 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> Message-ID: On Thu, Oct 9, 2014 at 5:13 PM, Baldur Norddahl wrote: > But all this are customer facing interfaces, which do not really qualify > for "point to point" links. I might consider adding interface addressing > for IPv6, but for me IPv4 was the primary design parameter. Having IPv6 > mirror the IPv4 setup means I have to think less about the setup. And we > are really constrained to use as few IPv4 addresses as possible. We only > got 1024 from RIPE and have to buy any additional at great expense. Hi Baldur, If that's convenient, more power to you. I can think of nothing which breaks doing it that way, just a couple things that might be easier if you do it the other way. > My colleges wanted to completely drop using public IP addressing in the > infrastructure. This, however, is positively 100% broken. Do not use private IPs on your routers. The TCP protocol depends on receiving ICMP type 3 (destination unreachable) messages from your router. Without ICMP messages needed for path MTU detection, TCP connections somewhat randomly drop into a black hole. Have a customer who connects to your web server but never receives the web page? Look for the firewall blocking ICMP. If those ICMP messages originate from private IP addresses, they will not reach their destination. Private IPs tend to be dropped at multiple locations out on the public Internet. So don't use private IPs on routers. Routers must be able to generate ICMP destination unreachables with the expectation that they _will_ get through. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From jtk at cymru.com Thu Oct 9 21:47:36 2014 From: jtk at cymru.com (John Kristoff) Date: Thu, 9 Oct 2014 16:47:36 -0500 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <5436F6DD.1080100@in-berlin.de> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> <5436F6DD.1080100@in-berlin.de> Message-ID: <20141009164736.3b1ebac8@localhost> On Thu, 09 Oct 2014 22:58:05 +0200 Christian Seitz wrote: > What I do not like at this UTRS idea is that I cannot announce a > prefix via BGP. Somebody has to inject it for me. I would like to > announce it in real time and not with delay because of manual > approval. While true today, it might not be true for long. It requires code to be written in order to perform the desired verification we want before blindly passing along an announcement. Code we're not motivated to write if there is insufficient interest in UTRS. Interest is looking good, so the code may soon follow. In other words, this a valid complaint, but it may have a limited life span. > One problem that I also see here is that this single entity could be > forced by someone (eg. government) to blackhole some prefix. If this > ever happens such a project will have to be terminated. I've heard this once before too. I admit we probably can't provide a satisfactory answer to some who will be so distrustful of government or influence peddling to win them over, but I'll try to offer a response that I hope is fairly reasonable and satisfies the majority, and presumably any of the actual participants. There are legal questions, maneuvers and responses that might be interesting to speculate on, but I'll say simply this. Team Cymru, while established and operated within the U.S., is a global organization with team members outside of the U.S. and we rely heavily on the cooperation of global partners to do what we do. If we could be compelled to announce a black hole by someone, government or otherwise, the cooperation and inherent trust we might have with the Internet community is probably gone and we are likely finished as an organization. It would be counter to our very existence and so on that basis I hope most would agree is extremely unlikely to occur. Now if someone came up to me with a gun to my head and said type the equivalent of "ip route foonet mask 192.0.2.1" or die, I might just type it out of self preservation. > We also had some DDoS attacks via IPv6. I think it's important to > also have such a service for IPv6. Starting with IPv4 is ok and > better than nothing, but IPv6 should not be on the roadmap for > 2018 ;-) You are only the second person I've heard from to explicitly state as such. This is actually not terribly hard to do and I'm pretty certain could be done way before 2018. Simple to start, careful and necessary improvements as we go. Thanks for your comments Chris, John From SNaslund at medline.com Thu Oct 9 22:02:43 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Oct 2014 22:02:43 +0000 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40124FB9DB4@MUNPRDMBXA1.medline.com> Yes, the BART case is different because we are talking about a public safety functionality. It really does not even matter who owns the repeaters. Let's say one of the carriers suddenly shuts down their very own cell sites to purposely deny public service. You can almost guarantee that an FCC enforcement action will result because carriers have a public safety responsibility. The state communications commission could even pull your license for that and the FCC could ultimately pull your spectrum licenses for using a public resource in a way not beneficial to the public. BART disrupting cell repeaters is tantamount to you doing anything to disrupt 911 service which is illegal whether you own the gear or not. I don't know what the exact rule currently is but I'm sure it would take someone like Homeland Security to shut down a cellular network for "national security" reasons. For example, interrupting a cellular bomb detonator or a coordinated terrorist attack. The legal concept of "greater good" comes into effect at that point. As a common carrier, I know I would not shut down anything that affects 911 service deliberately without either the proper notifications taking place or a federal court order in my hand (and it better be federal because those are the laws you are asking me to throw out here). The funny thing about cell service (or repeaters in this case) is that there isn't usually a mandate to provide coverage in any particular area but once you provide it you are on the hook to maintain it and not purposely disrupt it. Again, it is the intent in this case that matters. If BART had a maintenance problem or the equipment was damaged, they would be off the hook but they purposely interrupted the service to deny communications services to a group of users. Cell sites go down all the time for maintenance scheduled or otherwise but if you are doing it to purposely deny service, it's another story. Again, intent matters...a lot. I definitely see abuse of authority (not really a criminal act in itself, but not nice for sure) and for sure civil liability, not so much a 1st Amendment issue since the government is under no real obligation to give you the means to communicate (like repeaters). It's the 911 service disruption that is most criminal here. Steve >However, that's not what was being discussed in the BART example. In this case, repeaters with unclear ownership operated by cellular providers were shut down by BART authorities to try and disrupt a protest. That's not active jamming, so most likely, not an FCC issue. There are other >areas of concern, however, such as 1st amendment violations, abuse of authority, potential civil liability if anyone was unable to reach 911 in an expected manner, etc. >Owen From baldur.norddahl at gmail.com Thu Oct 9 22:04:46 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 10 Oct 2014 00:04:46 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> Message-ID: On 9 October 2014 23:18, Roland Dobbins wrote: > > On Oct 10, 2014, at 4:13 AM, Baldur Norddahl > wrote: > > > My colleges wanted to completely drop using public IP addressing in the > infrastructure. > > Your colleagues are wrong. Again, see RFC6752. > Yes, for using private IP addressing RFC 6752 applies and it is why we are not doing it. But you seem to completely fail to understand that RFC 6752 does not apply to the proposed solution. NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. Traceroute works. ICMP works. There are no private IP addresses that gets filtered. > I am wondering if all the nay sayers would not agree that is it better to > have a single public loopback address shared between all my interfaces, > than to go with private addressing completely? > > This is a false dichotomy. > > > Because frankly, that is the alternative. > > It isn't the only alternative. The *optimal* alternative is to use > publicly-routable link addresses, and then protect your infrastructure > using iACLs, GTSM, CoPP, et. al. > > I will as soon as you send me the check to buy addresses for all my links. I got a few. But it appears you do not realize that we ARE using public IPs for our infrastructure. And we ARE using ACLs for protecting it. We are not using addresses for LINKS, neither public nor private. And it is not for security but to conserve expensive address space. The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply. What started this thread was the simple observation that you can do the same with IPv6. In that case I am doing it because it is simpler to do the same thing on both protocols. And frankly I am not seeing the disadvantages put fourth so far as being anything worth taking extra management work for. What I am mostly getting from the responses here are not much useful, other than a lot of people screaming he his doing something different so he must be an idiot :-(. Well aside from Bill, which is apparently doing the same thing for the same reason (cost). Regards, Baldur From SNaslund at medline.com Thu Oct 9 22:19:40 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Oct 2014 22:19:40 +0000 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <20141009164736.3b1ebac8@localhost> References: <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> <5436F6DD.1080100@in-berlin.de> <20141009164736.3b1ebac8@localhost> Message-ID: <9578293AE169674F9A048B2BC9A081B40124FB9E1F@MUNPRDMBXA1.medline.com> I understand the concerns but it seems to me that there are already plenty of ways for any large government to black hole whatever they want and they do not need UTRS to do so. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race. It's a stigma thing like the different between launching the first nuke vs. being the responder. We all know they do a lot of cyber stuff out there but it is mostly behind a veil of deniability. First, if they have access to a tier 1 carrier (or at least enough carriers to make an impact) in their jurisdiction they could just order that carrier to do it with whatever court system (or not) is required. Most large governments also have enough connectivity to bury a route by brute force. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race and possibly losing easy access to that resource. We all know they do a lot of cyber crime stuff out there but it is mostly behind a veil of deniability. There has actually been more black hole events that occur by accident or as part of denial of service attacks than government launched. The global routing structure of the Internet has always been highly cooperative and vulnerable to a bad actor at a lot of points. My only real concern with UTRS is designing a system that cannot be gamed or exploited to turn it into a very effective DoS weapon system. I admit that I don't know enough about how it works to make that decision yet. Steven Naslund Chicago IL >Subject: Re: Unwanted Traffic Removal Service (UTRS) >On Thu, 09 Oct 2014 22:58:05 +0200 >Christian Seitz wrote: >> What I do not like at this UTRS idea is that I cannot announce a >> prefix via BGP. Somebody has to inject it for me. I would like to >> announce it in real time and not with delay because of manual >> approval. >While true today, it might not be true for long. It requires code to be written in order to perform the desired verification we want before blindly passing along an announcement. Code we're not motivated to write if there is >insufficient interest in UTRS. Interest is looking good, so the code may soon follow. In other words, this a valid complaint, but it may have a limited life span. >> One problem that I also see here is that this single entity could be >> forced by someone (eg. government) to blackhole some prefix. If this >> ever happens such a project will have to be terminated. >I've heard this once before too. I admit we probably can't provide a satisfactory answer to some who will be so distrustful of government or influence peddling to win them over, but I'll try to offer a response that I hope is >fairly reasonable and satisfies the majority, and presumably any of the actual participants. >There are legal questions, maneuvers and responses that might be interesting to speculate on, but I'll say simply this. Team Cymru, while established and operated within the U.S., is a global organization with team members outside >of the U.S. and we rely heavily on the cooperation of global partners to do what we do. If we could be compelled to announce a black hole by someone, government or otherwise, the cooperation and inherent trust we might have with >the Internet community is probably gone and we are likely finished as an organization. It would be counter to our very existence and so on that basis I hope most would agree is extremely unlikely to occur. Now if someone came up to >me with a gun to my head and said type the equivalent of "ip route foonet mask 192.0.2.1" or die, I might just type it out of self preservation. >> We also had some DDoS attacks via IPv6. I think it's important to also >> have such a service for IPv6. Starting with IPv4 is ok and better than >> nothing, but IPv6 should not be on the roadmap for >> 2018 ;-) >You are only the second person I've heard from to explicitly state as such. This is actually not terribly hard to do and I'm pretty certain could be done way before 2018. Simple to start, careful and necessary improvements as we >go. >Thanks for your comments Chris, >John From ak47 at gawul.net Thu Oct 9 22:20:11 2014 From: ak47 at gawul.net (Andrew Koch) Date: Thu, 9 Oct 2014 17:20:11 -0500 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users Message-ID: <20141009222011.GK7948@bucket.gawul.net> Hello Colleagues, The NANOG mailing list had a discussion several months back regarding changes that Yahoo made to their DMARC settings. Over the past day, the NANOG mailing list has received a number of posts from yahoo.com mail users. This triggered bounce action on nearly 300 NANOG mailing list subscriptions as the receiving mail systems were complying with the DMARC settings that Yahoo has set. All subscriptions that had been disabled have been re-enabled at this time. To correct this moving forward, selective rewriting of the from header has been recommended, but requires an upgrade to the Mailman software. While we would like to have no impact to our subscribers, the selective rewrite and upgrade are not immediately available. An expeditious implementation of the upgrade is being worked on. As a temporary measure, the NANOG mailing list will be holding posts that come from yahoo.com users. We are not wishing to restrict posting, however posts from yahoo.com accounts are causing operational issues with the mailing list. Once a final timeline for the upgrade procedure and selective rewrite are available, we will let you know. Best Regards, Andrew Koch NANOG Communications Committee From rdobbins at arbor.net Thu Oct 9 22:37:27 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 05:37:27 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> Message-ID: <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> On Oct 10, 2014, at 5:04 AM, Baldur Norddahl wrote: > NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. As far as Section 8 goes, you're even worse off than if you were using private IP addresses. And see Section 9. My point is that *analogous* issues arise with unnumbered interfaces. Loopback-only addressing isn't sufficient for troubleshooting purposes and other routine operational activities. > The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore > RFC 6752 does not apply. Again, see Section 9. *Analogous* issues arise in networks with unnumbered interfaces. I'm aware that PMTU-D will work with the setup you propose. You might want to take a look at Appendix A, too. It sounds as if there is an unfortunate shortfall in the budget for your organization. Personally, I wouldn't attempt to build and operate a network which required more funding than was made available in order to implement it optimally. Doing things the suboptimal way in IPv4 isn't a valid reason replicate those suboptimalities in IPv6. I wish you luck in troubleshooting an infrastructure full of unnumbered links - I've done it, and it isn't fun. > What I am mostly getting from the responses here are not much useful, other than a lot of people screaming he his doing something different so he must be an idiot That is incorrect. You've been told repeatedly that troubleshooting unnumbered links is highly suboptimal; you've merely dismissed those arguments for reasons best known to yourself. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From blair.trosper at gmail.com Thu Oct 9 23:07:46 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 9 Oct 2014 18:07:46 -0500 Subject: GApps admin = rogered Message-ID: Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=en&v=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. I'd call for premium support, but I can't even see that. Again, a friendly heads up and nudge that perhaps the status page should at least be updated to reflect the fact that it's non-operational. From paigeadele at gmail.com Thu Oct 9 23:12:14 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Fri, 10 Oct 2014 02:12:14 +0300 Subject: Marriott wifi blocking In-Reply-To: <9578293AE169674F9A048B2BC9A081B40124FB9DB4@MUNPRDMBXA1.medline.com> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40124FB9DB4@MUNPRDMBXA1.medline.com> Message-ID: <5437164E.7090704@gmail.com> On 10/10/14 01:02, Naslund, Steve wrote: > Yes, the BART case is different because we are talking about a public safety functionality. It really does not even matter who owns the repeaters. Let's say one of the carriers suddenly shuts down their very own cell sites to purposely deny public service. You can almost guarantee that an FCC enforcement action will result because carriers have a public safety responsibility. The state communications commission could even pull your license for that and the FCC could ultimately pull your spectrum licenses for using a public resource in a way not beneficial to the public. BART disrupting cell repeaters is tantamount to you doing anything to disrupt 911 service which is illegal whether you own the gear or not. I don't know what the exact rule currently is but I'm sure it would take someone like Homeland Security to shut down a cellular network for "national security" reasons. For example, interrupting a cellular bomb detonator or a coordinated terrorist attack. The legal concept of "greater good" comes into effect at that point. > > As a common carrier, I know I would not shut down anything that affects 911 service deliberately without either the proper notifications taking place or a federal court order in my hand (and it better be federal because those are the laws you are asking me to throw out here). The funny thing about cell service (or repeaters in this case) is that there isn't usually a mandate to provide coverage in any particular area but once you provide it you are on the hook to maintain it and not purposely disrupt it. Again, it is the intent in this case that matters. If BART had a maintenance problem or the equipment was damaged, they would be off the hook but they purposely interrupted the service to deny communications services to a group of users. Cell sites go down all the time for maintenance scheduled or otherwise but if you are doing it to purposely deny service, it's another story. Again, intent matters...a lot. > > I definitely see abuse of authority (not really a criminal act in itself, but not nice for sure) and for sure civil liability, not so much a 1st Amendment issue since the government is under no real obligation to give you the means to communicate (like repeaters). It's the 911 service disruption that is most criminal here. > > Steve > > >> However, that's not what was being discussed in the BART example. In this case, repeaters with unclear ownership operated by cellular providers were shut down by BART authorities to try and disrupt a protest. That's not active jamming, so most likely, not an FCC issue. There are other >areas of concern, however, such as 1st amendment violations, abuse of authority, potential civil liability if anyone was unable to reach 911 in an expected manner, etc. >> Owen > see if you can get tor browser to work... download it from torproject.org From blair.trosper at gmail.com Thu Oct 9 23:23:44 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 9 Oct 2014 18:23:44 -0500 Subject: [outages] GApps admin = rogered In-Reply-To: References: Message-ID: Was not there at the time I sent the email. I was thorough in checking. 100% sure. On Thu, Oct 9, 2014 at 6:22 PM, Mitch Patterson wrote: > Shows an issue to me > > TimeDescription > 10/9/14 7:11 PM > We're investigating reports of an issue with Admin console. We will > provide more information shortly. > Users are seeing the Admin console refresh continuously on loading. > > On Thu, Oct 9, 2014 at 7:07 PM, Blair Trosper via Outages < > outages at outages.org> wrote: > >> Just a heads up to our friends at Google Apps. >> >> Despite the status page saying all is peachy: >> http://www.google.com/appsstatus#hl=en&v=status >> >> ...the administration page for any Google Apps for domains is totally >> rogered. It's either an endless redirect loop or a deluge of errors. >> >> I'd call for premium support, but I can't even see that. >> >> Again, a friendly heads up and nudge that perhaps the status page should >> at least be updated to reflect the fact that it's non-operational. >> >> _______________________________________________ >> Outages mailing list >> Outages at outages.org >> https://puck.nether.net/mailman/listinfo/outages >> >> > From ryan.landry at gmail.com Thu Oct 9 23:30:43 2014 From: ryan.landry at gmail.com (ryanL) Date: Thu, 9 Oct 2014 16:30:43 -0700 Subject: [outages] GApps admin = rogered In-Reply-To: References: Message-ID: i confirm this issue is apparent for us as well. From mloftis at wgops.com Thu Oct 9 23:32:44 2014 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 9 Oct 2014 16:32:44 -0700 Subject: GApps admin = rogered In-Reply-To: References: Message-ID: This is 4-5 minutes after the OP emailed On Thursday, October 9, 2014, Mitch Patterson via Outages < outages at outages.org> wrote: > Shows an issue to me > > TimeDescription > 10/9/14 7:11 PM > We're investigating reports of an issue with Admin console. We will > provide more information shortly. > Users are seeing the Admin console refresh continuously on loading. > > On Thu, Oct 9, 2014 at 7:07 PM, Blair Trosper via Outages < > outages at outages.org > > wrote: > >> Just a heads up to our friends at Google Apps. >> >> Despite the status page saying all is peachy: >> http://www.google.com/appsstatus#hl=en&v=status >> >> ...the administration page for any Google Apps for domains is totally >> rogered. It's either an endless redirect loop or a deluge of errors. >> >> I'd call for premium support, but I can't even see that. >> >> Again, a friendly heads up and nudge that perhaps the status page should >> at least be updated to reflect the fact that it's non-operational. >> >> _______________________________________________ >> Outages mailing list >> Outages at outages.org >> https://puck.nether.net/mailman/listinfo/outages >> >> > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From baldur.norddahl at gmail.com Thu Oct 9 23:37:51 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 10 Oct 2014 01:37:51 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> Message-ID: On 10 October 2014 00:37, Roland Dobbins wrote: > > On Oct 10, 2014, at 5:04 AM, Baldur Norddahl > wrote: > > > NONE of the problems listed in RFC 6752 are a problem with using > unnumbered interfaces. > > As far as Section 8 goes, you're even worse off than if you were using > private IP addresses. > I see nothing in section 8 that is broken in my network. My public loopback address is in DNS and reverse DNS works fine too. > > And see Section 9. > I see nothing in section 9 that is broken in my network. Traceroute works perfectly. You do not get a string of * * * back. You get the IP of the loopback which in turn goes through reverse DNS to tell you what router is processing that step. The only difference between a traceroute using unnumbered interfaces and using numbered interfaces, is that you only get information about the router and not the link. > My point is that *analogous* issues arise with unnumbered interfaces. > Loopback-only addressing isn't sufficient for troubleshooting purposes and > other routine operational activities. > That is really up to me? 99% of my interfaces are unnumbered by the virtue of being on access switches that simply have no layer 3 capability other than management. Nobody is crazy enough to assign /30s to end users anymore anyway. It is not my business to sell backbone links. I sell end user links and those are unnumbered in my network and everyone else too. I claim this argument is mostly BS. Information about link in traceroute is nice to have. It is not need to have. I have never been in doubt of what traceroute was telling me. Besides I have more effective methods to troubleshoot my links. > > The thing is that we will only use ONE public address for a router. And > the router will be using that address for traceroute, ICMP et al. And > therefore > > RFC 6752 does not apply. > > Again, see Section 9. *Analogous* issues arise in networks with > unnumbered interfaces. I'm aware that PMTU-D will work with the setup you > propose. > That is not the only thing that works. Everything works. The only "problem" anyone has been able to point to is that you lose link information in traceroute and get host information in its stead. It is a small loss. > > You might want to take a look at Appendix A, too. > What about it? That is incorrect. You've been told repeatedly that troubleshooting > unnumbered links is highly suboptimal; you've merely dismissed those > arguments for reasons best known to yourself. > Maybe because on that one topic I am more an expert than you: I have experience troubleshooting my network, you don't. Regards, Baldur From royce at techsolvency.com Fri Oct 10 01:38:39 2014 From: royce at techsolvency.com (Royce Williams) Date: Thu, 9 Oct 2014 17:38:39 -0800 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: <20141009222011.GK7948@bucket.gawul.net> References: <20141009222011.GK7948@bucket.gawul.net> Message-ID: On Thu, Oct 9, 2014 at 2:20 PM, Andrew Koch wrote: > To correct this moving forward, selective rewriting of the from header > has been recommended, but requires an upgrade to the Mailman software. If the admins have settled on a best practice, it could help other Mailman operators like myself. Two questions spring to mind: 1. With the planned method, how will reply behavior be affected? 2. Will this be an upgrade to 2.1.16, or a pre-release version of 2.1.18, or something else? >From http://wiki.list.org/display/DEV/DMARC : In 2.1 16 a from_is_list feature was implemented which if enabled by a site configuration option would offer a list admin the ability to either: * Rewrite (Munge) the From: header with the posters name 'via the list' and the list's address and merge the poster's address into Reply-To: or * Wrap the message as a message/rfc822 sub-part in a MIME format outer message with From: and Reply-To: as above. Implemented now for release in 2.1.18 are the following: * The from_is_list feature from 2.1.16 is always available. * There are new settings in Privacy options - Sender filters: ** dmarc_moderaction_action is a five valued setting with values *** Accept - accept the post without rewriting From: or wrapping the message *** Munge From - rewrite the From: and Reply-To: as in from_is_list *** Wrap Message - wrap the message as in from_is_list *** Reject - reject the post *** Discard - Discard the post ** dmarc_moderaction_notice is a custom reject message to replace the default Reject message. * The above options other than Accept override the from_is_list setting for messages whose original From: domain publishes a DMARC policy of p=reject or p=quarantine. A per-list option is available to limit this to just p=reject or to apply it to either p=reject or p=quarantine. If the option is Accept, the from_is_list setting applies. * There is a site option to set the default for dmarc_moderaction_action and list admins may not set the action to a setting which is above the site default in the above list. E.g., if the site default is Reject, list admins can only set Reject or Discard; if the site default is Munge From, list admins can select anything but Accept. Royce From larrysheldon at cox.net Fri Oct 10 01:46:05 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 20:46:05 -0500 Subject: GApps admin = rogered In-Reply-To: <1B8Z1p00e1cZc5601B8v4S> References: <1B8Z1p00e1cZc5601B8v4S> Message-ID: <54373A5D.7020703@cox.net> On 10/9/2014 18:07, Blair Trosper wrote: > Just a heads up to our friends at Google Apps. > > Despite the status page saying all is peachy: > http://www.google.com/appsstatus#hl=en&v=status > > ...the administration page for any Google Apps for domains is totally > rogered. It's either an endless redirect loop or a deluge of errors. For me and any others here in the "F" row, a question about the use and meaning and implication of the use of the word "rogered". Until this very moment that word has ALWAYS (correctly used) meant "received" or "receipt acknowledged" and OCCASIONALLY (under the influence of [H|B]ollywood) incorrectly "I agree". What does it mean here? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Fri Oct 10 02:18:02 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 09 Oct 2014 21:18:02 -0500 Subject: GApps admin = rogered In-Reply-To: <1DrR1p0130mWXTC01DrTWy> References: <54373A5D.7020703@cox.net> <1DrR1p0130mWXTC01DrTWy> Message-ID: <543741DA.8040400@cox.net> On 10/9/2014 20:51, Harald Koch wrote: > http://lmgtfy.com/?q=rogered > > The first entries are all 'correct' for the intended slang use, in this > case. I have lived a very sheltered life. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From tore at fud.no Fri Oct 10 05:25:40 2014 From: tore at fud.no (Tore Anderson) Date: Fri, 10 Oct 2014 07:25:40 +0200 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> Message-ID: <54376DD4.2040800@fud.no> * Baldur Norddahl > Why do people assign addresses to point-to-point links at all? You can just > use a host /128 route to the loopback address of the peer. Saves you the > hassle of coming up with new addresses for every link. Why do you need those host routes? Most IPv6 IGPs work just fine without global addresses or host routes. https://tools.ietf.org/html/draft-ietf-opsec-lla-only-11 Tore From hank at efes.iucc.ac.il Fri Oct 10 06:49:39 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 10 Oct 2014 09:49:39 +0300 Subject: Unwanted Traffic Removal Service (UTRS) In-Reply-To: <5436F6DD.1080100@in-berlin.de> References: <20141008144238.GE10316@Vurt.local> <20141008085900.3b6f2a24@localhost> <20141008144238.GE10316@Vurt.local> Message-ID: <5.1.1.6.2.20141010094749.020a7118@efes.iucc.ac.il> At 22:58 09/10/2014 +0200, Christian Seitz wrote: >Allowing ASN to blackhole a prefix based on AS sets is dangerous from my point >of view. In the RIPE database you can add any AS to your AS set without >verification. Ok, it doesn't make much difference because most IP transit >providers also filter on the AS set, but a worldwide announced /24 prefix is >much more visible than a /32 blackhole route that is only announced to the >participants. See: http://www.ripe.net/ripe/mail/archives/routing-wg/2014-June/002696.html -Hank From me at anuragbhatia.com Fri Oct 10 12:57:35 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 10 Oct 2014 18:27:35 +0530 Subject: astraceroute on MAC Message-ID: Was wondering if anyone got the astraceroute tool working on MAC? http://www.shrubbery.net/astraceroute/ Tried compiling as well as via Mac ports but no success. Does anyone knows any other alternate similar tool? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From mikea at mikea.ath.cx Fri Oct 10 13:43:59 2014 From: mikea at mikea.ath.cx (Mike A) Date: Fri, 10 Oct 2014 08:43:59 -0500 Subject: GApps admin = rogered In-Reply-To: <54373A5D.7020703@cox.net> References: <1B8Z1p00e1cZc5601B8v4S> <54373A5D.7020703@cox.net> Message-ID: <20141010134359.GC22761@mikea.ath.cx> On Thu, Oct 09, 2014 at 08:46:05PM -0500, Larry Sheldon wrote: > On 10/9/2014 18:07, Blair Trosper wrote: > >Just a heads up to our friends at Google Apps. > > > >Despite the status page saying all is peachy: > >http://www.google.com/appsstatus#hl=en&v=status > > > >...the administration page for any Google Apps for domains is totally > >rogered. It's either an endless redirect loop or a deluge of errors. > > > For me and any others here in the "F" row, a question about the use and > meaning and implication of the use of the word "rogered". > > Until this very moment that word has ALWAYS (correctly used) meant > "received" or "receipt acknowledged" and OCCASIONALLY (under the influence > of [H|B]ollywood) incorrectly "I agree". > > What does it mean here? It's Elizabethan English slang. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From niels=nanog at bakker.net Fri Oct 10 13:51:57 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 10 Oct 2014 15:51:57 +0200 Subject: astraceroute on MAC In-Reply-To: References: Message-ID: <20141010135157.GA13003@excession.tpb.net> * me at anuragbhatia.com (Anurag Bhatia) [Fri 10 Oct 2014, 14:59 CEST]: >Was wondering if anyone got the astraceroute tool working on MAC? [..] >Does anyone knows any other alternate similar tool? Why bother when the supplied traceroute supports -a already? -- Niels. -- From SNaslund at medline.com Fri Oct 10 14:03:48 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 10 Oct 2014 14:03:48 +0000 Subject: Marriott wifi blocking In-Reply-To: References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com>, Message-ID: You have to do both preferrably. You kill the wired port to get them off your LAN, but if they are also on one of your SSIDs or run an unsecured one the AP can bug light your clients. Given that there is an unauthorized intrusion on the wired side, I don't want him talking to my clients at all. Steven Naslund Chicago IL On Oct 9, 2014, at 7:42 PM, "Chris Marget" > wrote: On Thu, Oct 9, 2014 at 3:41 PM, Naslund, Steve > wrote: If you set up an AP and try to plug it into my wired infrastructure that's when the active stuff comes into effect because you have no right to add a device to my wired network. Hi Steve, You're not the first to express this sentiment. Do you mind if I ask why? I mean, if you *know* there's an AP on your wired network, wouldn't it be more effective to kill the wired port? Just curious... /chris From Valdis.Kletnieks at vt.edu Fri Oct 10 14:20:57 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Oct 2014 10:20:57 -0400 Subject: Marriott wifi blocking In-Reply-To: Your message of "Fri, 10 Oct 2014 14:03:48 -0000." References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com>, Message-ID: <92808.1412950857@turing-police.cc.vt.edu> On Fri, 10 Oct 2014 14:03:48 -0000, "Naslund, Steve" said: > the AP can bug light your clients. Only if your clients are configured to allow it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rsk at gsp.org Fri Oct 10 14:28:48 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 10 Oct 2014 10:28:48 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: <20141009222011.GK7948@bucket.gawul.net> References: <20141009222011.GK7948@bucket.gawul.net> Message-ID: <20141010142848.GA2994@gsp.org> FYI, I migrated to Mailman 2.1.18-1 shortly after Yahoo decided to break every mailing list on the Internet for no good reason. (It certainly has done nothing to mitigate the ongoing flow of spam, phishing and other abuse coming from Yahoo, which continues pretty much as it has for many years.) I can't recommend it, and I don't say that to denigrate the work of the Mailman developers, which has been (as usual) outstanding, even under duress. The problems I've encountered are that the changes in headers are confusing to lot of subscribers and I still see [some] rejections based on DMARC failures despite using the appropriate settings (supported by dnspython-1.11.1, which is required for 2.1.18-1 to work). I suppose I'd describe it in operational practice as "rickety" or "unreliable", at best. Yahoo has inflicted this on themselves by making an abrupt, ill-advised, unilateral decision without consulting with their peers and considering the large-scale implications of said decision. I don't see a good reason for NANOG's mailing list admins to go through a *lot* of work (including what will likely be user confusion/questions, if my experience is any guide) in order to accomodate this. I think a better approach would be to recommend that mailing list participants who want to actually participate should utilize a mail service appropriate for the purpose. ---rsk From owen at delong.com Fri Oct 10 14:45:12 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Oct 2014 07:45:12 -0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.! net> Message-ID: <87FFE8F6-7458-4428-BDC3-1523692523EC@delong.com> On Oct 9, 2014, at 3:04 PM, Baldur Norddahl wrote: > On 9 October 2014 23:18, Roland Dobbins wrote: > >> >> On Oct 10, 2014, at 4:13 AM, Baldur Norddahl >> wrote: >> >>> My colleges wanted to completely drop using public IP addressing in the >> infrastructure. >> >> Your colleagues are wrong. Again, see RFC6752. >> > > Yes, for using private IP addressing RFC 6752 applies and it is why we are > not doing it. But you seem to completely fail to understand that RFC 6752 > does not apply to the proposed solution. NONE of the problems listed in RFC > 6752 are a problem with using unnumbered interfaces. Traceroute works. ICMP > works. There are no private IP addresses that gets filtered. > >> I am wondering if all the nay sayers would not agree that is it better to >> have a single public loopback address shared between all my interfaces, >> than to go with private addressing completely? >> >> This is a false dichotomy. >> >>> Because frankly, that is the alternative. >> >> It isn't the only alternative. The *optimal* alternative is to use >> publicly-routable link addresses, and then protect your infrastructure >> using iACLs, GTSM, CoPP, et. al. >> >> > I will as soon as you send me the check to buy addresses for all my links. > I got a few. > > But it appears you do not realize that we ARE using public IPs for our > infrastructure. And we ARE using ACLs for protecting it. We are not using > addresses for LINKS, neither public nor private. And it is not for security > but to conserve expensive address space. Addresses are not expensive. You can get up to a /40 from ARIN for $500 one-tim and $100/year. Are you really trying to convince me that you have ore than 16.7 million links? (and that’s assuming you assign a /64 per link). I’m sorry, but this argument utterly fails under any form of analysis. Owen From rdobbins at arbor.net Fri Oct 10 14:53:17 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 10 Oct 2014 21:53:17 +0700 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <87FFE8F6-7458-4428-BDC3-1523692523EC@delong.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.! net> <87FFE8F6-7458-4428-BDC3-1523692523EC@delong.com> Message-ID: <0C2BE844-FB8E-416B-8EDE-F5273B9E4DD1@arbor.net> On Oct 10, 2014, at 9:45 PM, Owen DeLong wrote: > I’m sorry, but this argument utterly fails under any form of analysis. I think he's talking about IPv4 - and saying that since he apparently doesn't have the budget for enough IPv4 subnets to address his point-to-point links, he's inclined to repeat this suboptimal practice on the IPv6 side in the name of 'consistency'. But he knows best, and we oughtn't to try and dissuade him any further, as that just upsets him. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From randy at psg.com Fri Oct 10 14:54:48 2014 From: randy at psg.com (Randy Bush) Date: Fri, 10 Oct 2014 10:54:48 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: <20141010142848.GA2994@gsp.org> References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: > a better approach would be to recommend that mailing list participants > who want to actually participate should utilize a mail service > appropriate for the purpose. support From tschuh at vmware.com Fri Oct 10 13:22:31 2014 From: tschuh at vmware.com (Tim Schuh) Date: Fri, 10 Oct 2014 13:22:31 +0000 Subject: astraceroute on MAC In-Reply-To: Message-ID: Are you trying to accomplish something the stock traceroute on OS X can't currently do? The traceroute that came on my Mac (10.9.5 as of last update) can look up the ASN right out of the box. >$ traceroute Version 1.4a12+Darwin Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs] host [packetlen] >$ traceroute -a www.shrubbery.net traceroute to sea.shrubbery.net (129.250.47.99), 64 hops max, 52 byte packets 1 [AS0] 192.168.1.1 (192.168.1.1) 3.096 ms 2.282 ms 1.972 ms 2 [AS65534] 10.22.23.10 (10.22.23.10) 2.520 ms 2.516 ms 2.521 ms 3 [AS11427] rrcs-97-79-191-57.sw.biz.rr.com (97.79.191.57) 2.567 ms 3.346 ms 2.827 ms 4 [AS11427] 97.77.1.144 (97.77.1.144) 9.164 ms 9.079 ms 9.099 ms 5 [AS11427] tge0-8-0-1.grpvtx1102r.texas.rr.com (24.175.38.24) 10.252 ms 10.202 ms 12.026 ms 6 [AS11427] agg26.dllbtxlb02r.texas.rr.com (24.175.36.216) 11.589 ms 13.062 ms 11.802 ms 7 [AS11427] agg21.hstqtxl301r.texas.rr.com (24.175.49.8) 10.232 ms 9.047 ms 12.006 ms 8 [AS7843] 107.14.17.138 (107.14.17.138) 9.211 ms 9.390 ms 12.169 ms 9 [AS19548] ae-0-0.cr0.dfw10.tbone.rr.com (66.109.6.39) 14.574 ms 17.712 ms 19.103 ms 10 [AS7843] ae0.pr1.dfw10.tbone.rr.com (107.14.17.232) 9.344 ms [AS7843] 107.14.19.97 (107.14.19.97) 13.881 ms [AS7843] ae0.pr1.dfw10.tbone.rr.com (107.14.17.232) 8.811 ms 11 [AS2828] 207.86.210.125 (207.86.210.125) 14.502 ms 9.794 ms 9.757 ms 12 [AS2828] 207.88.14.182.ptr.us.xo.net (207.88.14.182) 27.368 ms 14.018 ms 14.497 ms 13 [AS2828] 207.88.14.189.ptr.us.xo.net (207.88.14.189) 17.069 ms 14.076 ms 30.312 ms 14 [AS2914] ae-6.r01.dllstx04.us.bb.gin.ntt.net (129.250.9.157) 10.825 ms 10.778 ms 10.300 ms 15 [AS2914] ae-1.r21.dllstx09.us.bb.gin.ntt.net (129.250.2.198) 10.550 ms 10.794 ms 13.712 ms 16 [AS2914] ae-4.r21.snjsca04.us.bb.gin.ntt.net (129.250.4.25) 55.323 ms 55.040 ms 57.121 ms 17 [AS2914] ae-3.r20.sttlwa01.us.bb.gin.ntt.net (129.250.3.125) 69.764 ms 69.824 ms 68.002 ms 18 [AS2914] ae-1.r05.sttlwa01.us.bb.gin.ntt.net (129.250.5.47) 67.978 ms 67.224 ms 65.670 ms 19 [AS2914] sea.shrubbery.net (129.250.47.99) 62.036 ms 61.302 ms 62.941 ms On 10/10/14, 7:57 AM, "Anurag Bhatia" wrote: >Was wondering if anyone got the astraceroute tool working on MAC? > >https://urldefense.proofpoint.com/v1/url?u=http://www.shrubbery.net/astrac >eroute/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=7fly2PNWrE19T4IPOWDPwwjyVNmT >Cx%2BLXA%2FHSA%2BizVc%3D%0A&m=Iam2x1KTiLt4zE2bDO0Ik81iE9yUGF0LC0SXENouMVs% >3D%0A&s=a831bad4738fbc517ef5eee7b2191f9d250169fb5210b85da62ca1e5f1f8c96e > > > >Tried compiling as well as via Mac ports but no success. > > >Does anyone knows any other alternate similar tool? > > > >Thanks. > >-- > > >Anurag Bhatia >anuragbhatia.com > >Linkedin >agbhatia21&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=7fly2PNWrE19T4IPOWDPwwjyV >NmTCx%2BLXA%2FHSA%2BizVc%3D%0A&m=Iam2x1KTiLt4zE2bDO0Ik81iE9yUGF0LC0SXENouM >Vs%3D%0A&s=ea7520d15e592b8c87594191526a6cda8de60c0718d0a53c2353f9fa7ad5598 >e> | Twitter >tia&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=7fly2PNWrE19T4IPOWDPwwjyVNmTCx%2 >BLXA%2FHSA%2BizVc%3D%0A&m=Iam2x1KTiLt4zE2bDO0Ik81iE9yUGF0LC0SXENouMVs%3D%0 >A&s=727bc643a95055830d1604a2574ca3e85f019566b8d74c95eded8d58a768e8f6> >Skype: anuragbhatia.com > >PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From morrowc.lists at gmail.com Fri Oct 10 15:05:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Oct 2014 11:05:49 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: On Fri, Oct 10, 2014 at 10:54 AM, Randy Bush wrote: >> a better approach would be to recommend that mailing list participants >> who want to actually participate should utilize a mail service >> appropriate for the purpose. > > support to be fair, this means EITHER one which does not DMARC mark messages OR one which disrespects DMARC. Right? -chris From SNaslund at medline.com Fri Oct 10 15:05:50 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 10 Oct 2014 15:05:50 +0000 Subject: Marriott wifi blocking In-Reply-To: <92808.1412950857@turing-police.cc.vt.edu> References: <890706.4267.1412448462617.JavaMail.root@benjamin.baylink.com> <54304758.7070509@mtcc.com> <7F6F3626-229B-4688-8D63-A87829CE20D3@delong.com> <20141005005807.GA24831@panix.com> <17BA2B2C-B2B0-48B0-8312-AF37CB62D44B@delong.com> <20141005231312.GA18326@panix.com> <9578293AE169674F9A048B2BC9A081B40124FB9B8C@MUNPRDMBXA1.medline.com>, , <92808.1412950857@turing-police.cc.vt.edu> Message-ID: Now that BYOD is so popular, you don't control all of your client configurations so you better find a way to try to secure them as much as possible from the network side. Defense in depth is what it is. It a lot easy to manage one wireless IDP/IDS than a thousand clients that get replaced and updated on a six month cycle. Also, if you are required to meet PCI/HIPPA/DoD regs then securing the client will not be enough to satisfy the regulators. Steven Naslund Chicago IL > On Oct 10, 2014, at 9:21 AM, "Valdis.Kletnieks at vt.edu" wrote: > > On Fri, 10 Oct 2014 14:03:48 -0000, "Naslund, Steve" said: >> the AP can bug light your clients. > > Only if your clients are configured to allow it. From randy at psg.com Fri Oct 10 15:10:59 2014 From: randy at psg.com (Randy Bush) Date: Fri, 10 Oct 2014 11:10:59 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: >>> a better approach would be to recommend that mailing list participants >>> who want to actually participate should utilize a mail service >>> appropriate for the purpose. >> >> support > > to be fair, this means EITHER one which does not DMARC mark messages > OR one which disrespects DMARC. Right? to one which respects both mailing list subscribers and admins randy From steve at blighty.com Fri Oct 10 15:31:27 2014 From: steve at blighty.com (Steve Atkins) Date: Fri, 10 Oct 2014 08:31:27 -0700 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: On Oct 10, 2014, at 8:05 AM, Christopher Morrow wrote: > On Fri, Oct 10, 2014 at 10:54 AM, Randy Bush wrote: >>> a better approach would be to recommend that mailing list participants >>> who want to actually participate should utilize a mail service >>> appropriate for the purpose. >> >> support +1 > > to be fair, this means EITHER one which does not DMARC mark messages > OR one which disrespects DMARC. Right? One which does not publish DMARC p=reject. If any recipient honors published DMARC records then every participant using a domain that publishes DMARC p=reject will break things. If your domain publishes p=reject it should not have any users that participate in mailing lists. Cheers, Steve From mike at mtcc.com Fri Oct 10 16:07:08 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 10 Oct 2014 09:07:08 -0700 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: <5438042C.30700@mtcc.com> On 10/10/2014 08:10 AM, Randy Bush wrote: >>>> a better approach would be to recommend that mailing list participants >>>> who want to actually participate should utilize a mail service >>>> appropriate for the purpose. >>> support >> to be fair, this means EITHER one which does not DMARC mark messages >> OR one which disrespects DMARC. Right? > to one which respects both mailing list subscribers and admins > > What surprises me is that the dmarc crowd (nee ADSP) surely knows all about this as it's been known for going on 10 years that this is what would happen. isn't one of the wg chairs a Y!'er too? Mike From ops.lists at gmail.com Fri Oct 10 16:18:26 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 10 Oct 2014 21:48:26 +0530 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: <5438042C.30700@mtcc.com> References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> <5438042C.30700@mtcc.com> Message-ID: Call it triage. When a minuscule amount of mailing list traffic is weighed against huge volumes of forged spam and phish... On 10-Oct-2014 9:40 pm, "Michael Thomas" wrote: > On 10/10/2014 08:10 AM, Randy Bush wrote: > >> a better approach would be to recommend that mailing list participants >>>>> who want to actually participate should utilize a mail service >>>>> appropriate for the purpose. >>>>> >>>> support >>>> >>> to be fair, this means EITHER one which does not DMARC mark messages >>> OR one which disrespects DMARC. Right? >>> >> to one which respects both mailing list subscribers and admins >> >> >> > What surprises me is that the dmarc crowd (nee ADSP) surely knows all > about this as it's been > known for going on 10 years that this is what would happen. isn't one of > the wg chairs a Y!'er too? > > Mike > From royce at techsolvency.com Fri Oct 10 16:21:54 2014 From: royce at techsolvency.com (Royce Williams) Date: Fri, 10 Oct 2014 08:21:54 -0800 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: On Fri, Oct 10, 2014 at 7:31 AM, Steve Atkins wrote: > If your domain publishes p=reject it should not have any users > that participate in mailing lists. Like many, I was pretty unhappy (and busy) with the unilateral changes made by Yahoo and AOL. But this understandable stance may change. Neither of these domains is known for being heavily saturated with geeks. If Gmail started using p=reject, that might shake the tree a little more. But other than providing more warning, what would have been a better way to start eliminating forged senders? Everything I've read indicates that both Yahoo and AOL did this with eyes wide open. Assuming that eliminating forged senders is the end goal, maybe forcing the issue was the only way to move forward? What other theory about their motivation makes sense? Royce From jimpop at gmail.com Fri Oct 10 16:29:30 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 10 Oct 2014 12:29:30 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: On Fri, Oct 10, 2014 at 12:21 PM, Royce Williams wrote: > What other theory about their motivation makes sense? Most of the DMARC backers offer one or more services that compete with traditional mailinglists. -Jim P. From steve at blighty.com Fri Oct 10 16:53:56 2014 From: steve at blighty.com (Steve Atkins) Date: Fri, 10 Oct 2014 09:53:56 -0700 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> Message-ID: On Oct 10, 2014, at 9:21 AM, Royce Williams wrote: > On Fri, Oct 10, 2014 at 7:31 AM, Steve Atkins wrote: >> If your domain publishes p=reject it should not have any users >> that participate in mailing lists. > > Like many, I was pretty unhappy (and busy) with the unilateral changes > made by Yahoo and AOL. But this understandable stance may change. > Neither of these domains is known for being heavily saturated with > geeks. If Gmail started using p=reject, that might shake the tree a > little more. > > But other than providing more warning, what would have been a better > way to start eliminating forged senders? Everything I've read > indicates that both Yahoo and AOL did this with eyes wide open. > > Assuming that eliminating forged senders is the end goal, maybe > forcing the issue was the only way to move forward? What other theory > about their motivation makes sense? I'm fairly sure that their motivation wasn't anything like that clearly thought through - but their motivation doesn't really matter. Mailing list operators are stuck in the middle, and they have three reasonable choices. One is to rework their mail systems to selectively (or unselectively) replace the From: field. That's a lot of work, and makes the mailing list less usable for all users. (There's discussion in the DMARC IETF groups about redefining 5322 so as to put what is currently in the Sender: field into the From: field and creating a new field, that wouldn't be visible to the user, to contain what is currently in the From: field). Another is to be very, very careful about not breaking DKIM signatures on list mail. That's difficult because the things you have to do or not do change depending on how the submitted mail is signed (and Yahoo in particular have made some signing choices that make it particularly hard). The third option is to reject submissions from domains that publish p=reject (or, probably, p=quarantine), pushing the customer support costs onto those who are publishing p=reject records for users that participate in mailing lists. Cheers, Steve From goemon at anime.net Fri Oct 10 17:15:47 2014 From: goemon at anime.net (goemon at anime.net) Date: Fri, 10 Oct 2014 10:15:47 -0700 (PDT) Subject: peer1 contact? Message-ID: Can someone from peer1.net contact me? You are filtering your abuse at peer1.net mailbox. -Dan From magicsata at gmail.com Fri Oct 10 18:01:52 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 10 Oct 2014 19:01:52 +0100 Subject: peer1 contact? In-Reply-To: References: Message-ID: Just a heads up, Gmail gave me a warning about this email too so that may be your problem. On 10 October 2014 18:15, wrote: > Can someone from peer1.net contact me? > > You are filtering your abuse at peer1.net mailbox. > > -Dan > From tom at ninjabadger.net Fri Oct 10 18:04:20 2014 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 10 Oct 2014 19:04:20 +0100 Subject: peer1 contact? In-Reply-To: References: Message-ID: <54381FA4.7000302@ninjabadger.net> On 10/10/14 19:01, Alistair Mackenzie wrote: > Gmail gave me a warning about this email too so that may be your problem. Yeah, my provider classified it as spam too (which I think is a fairly basic SpamAssassin installation). -- Tom From cscora at apnic.net Fri Oct 10 18:14:35 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Oct 2014 04:14:35 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201410101814.s9AIEZ7X009617@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, TRNOG, 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 Oct, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 514566 Prefixes after maximum aggregation: 199271 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 254903 Total ASes present in the Internet Routing Table: 48265 Prefixes per ASN: 10.66 Origin-only ASes present in the Internet Routing Table: 36263 Origin ASes announcing only one prefix: 16360 Transit ASes present in the Internet Routing Table: 6141 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 118 Max AS path prepend of ASN ( 55644) 111 Prefixes from unregistered ASNs in the Routing Table: 1838 Unregistered ASNs in the Routing Table: 442 Number of 32-bit ASNs allocated by the RIRs: 7604 Number of 32-bit ASNs visible in the Routing Table: 5861 Prefixes from 32-bit ASNs in the Routing Table: 20745 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 338 Number of addresses announced to Internet: 2707058692 Equivalent to 161 /8s, 90 /16s and 112 /24s Percentage of available address space announced: 73.1 Percentage of allocated address space announced: 73.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176435 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 125819 Total APNIC prefixes after maximum aggregation: 36739 APNIC Deaggregation factor: 3.42 Prefixes being announced from the APNIC address blocks: 129713 Unique aggregates announced from the APNIC address blocks: 53522 APNIC Region origin ASes present in the Internet Routing Table: 4978 APNIC Prefixes per ASN: 26.06 APNIC Region origin ASes announcing only one prefix: 1190 APNIC Region transit ASes present in the Internet Routing Table: 855 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 118 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1124 Number of APNIC addresses announced to Internet: 735003456 Equivalent to 43 /8s, 207 /16s and 67 /24s Percentage of available APNIC address space announced: 85.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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, 150/8, 153/8, 163/8, 171/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: 171348 Total ARIN prefixes after maximum aggregation: 85249 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173263 Unique aggregates announced from the ARIN address blocks: 82654 ARIN Region origin ASes present in the Internet Routing Table: 16377 ARIN Prefixes per ASN: 10.58 ARIN Region origin ASes announcing only one prefix: 6102 ARIN Region transit ASes present in the Internet Routing Table: 1696 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 220 Number of ARIN addresses announced to Internet: 1081327808 Equivalent to 64 /8s, 115 /16s and 192 /24s Percentage of available ARIN address space announced: 57.2 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125372 Total RIPE prefixes after maximum aggregation: 63593 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 130602 Unique aggregates announced from the RIPE address blocks: 83097 RIPE Region origin ASes present in the Internet Routing Table: 17761 RIPE Prefixes per ASN: 7.35 RIPE Region origin ASes announcing only one prefix: 8204 RIPE Region transit ASes present in the Internet Routing Table: 2896 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3104 Number of RIPE addresses announced to Internet: 659620228 Equivalent to 39 /8s, 81 /16s and 1 /24s Percentage of available RIPE address space announced: 95.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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59141 Total LACNIC prefixes after maximum aggregation: 10806 LACNIC Deaggregation factor: 5.47 Prefixes being announced from the LACNIC address blocks: 67782 Unique aggregates announced from the LACNIC address blocks: 30606 LACNIC Region origin ASes present in the Internet Routing Table: 2347 LACNIC Prefixes per ASN: 28.88 LACNIC Region origin ASes announcing only one prefix: 650 LACNIC Region transit ASes present in the Internet Routing Table: 459 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1355 Number of LACNIC addresses announced to Internet: 171306112 Equivalent to 10 /8s, 53 /16s and 236 /24s Percentage of available LACNIC address space announced: 102.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12036 Total AfriNIC prefixes after maximum aggregation: 2837 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 12868 Unique aggregates announced from the AfriNIC address blocks: 4717 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 17.46 AfriNIC Region origin ASes announcing only one prefix: 214 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 58 Number of AfriNIC addresses announced to Internet: 59516160 Equivalent to 3 /8s, 140 /16s and 37 /24s Percentage of available AfriNIC address space announced: 59.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2946 11584 926 Korea Telecom 17974 2822 903 77 PT Telekomunikasi Indonesia 7545 2389 336 124 TPG Telecom Limited 4755 1918 412 189 TATA Communications formerly 9829 1652 1306 39 National Internet Backbone 9808 1534 6639 15 Guangdong Mobile Communicatio 4808 1404 2197 412 CNCGROUP IP network China169 9583 1305 104 532 Sify Limited 9498 1303 333 91 BHARTI Airtel Ltd. 7552 1185 1098 14 Viettel Corporation 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 2896 3688 51 BellSouth.net Inc. 22773 2892 2940 141 Cox Communications Inc. 18566 2046 379 182 MegaPath Corporation 7029 1854 1958 319 Windstream Communications Inc 20115 1804 1787 481 Charter Communications 4323 1634 1052 410 tw telecom holdings, inc. 6983 1516 867 252 ITC^Deltacom 30036 1477 308 619 Mediacom Communications Corp 701 1431 11258 715 MCI Communications Services, 22561 1305 408 237 CenturyTel Internet Holdings, 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 1822 296 348 TELLCOM ILETISIM HIZMETLERI A 20940 1489 577 1097 Akamai International B.V. 8402 1451 544 15 OJSC "Vimpelcom" 31148 1044 45 21 Freenet Ltd. 13188 1036 100 29 TOV "Bank-Inform" 8551 964 372 41 Bezeq International-Ltd 6849 834 356 26 JSC "Ukrtelecom" 12479 805 798 58 France Telecom Espana SA 6830 776 2334 431 Liberty Global Operations B.V 9198 675 346 29 JSC Kazakhtelecom 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 28573 2996 2305 143 NET Servi�os de Comunica��o S 10620 2994 485 245 Telmex Colombia S.A. 6147 1801 374 30 Telefonica del Peru S.A.A. 7303 1770 1178 236 Telecom Argentina S.A. 8151 1481 3009 434 Uninet S.A. de C.V. 18881 1237 1036 22 Global Village Telecom 6503 1110 434 60 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 915 2325 35 Tim Celular S.A. 27947 910 130 51 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 8452 1355 958 13 TE-AS 24863 950 280 26 Link Egypt (Link.NET) 6713 678 760 38 Office National des Postes et 36992 347 824 27 ETISALAT MISR 24835 307 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 231 19 6 Data Telecom Service 15706 186 17 6 Sudatel (Sudan Telecom Co. Lt 12258 174 26 71 MWEB CONNECT (PROPRIETARY) LI 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 28573 2996 2305 143 NET Servi�os de Comunica��o S 10620 2994 485 245 Telmex Colombia S.A. 4766 2946 11584 926 Korea Telecom 6389 2896 3688 51 BellSouth.net Inc. 22773 2892 2940 141 Cox Communications Inc. 17974 2822 903 77 PT Telekomunikasi Indonesia 7545 2389 336 124 TPG Telecom Limited 18566 2046 379 182 MegaPath Corporation 4755 1918 412 189 TATA Communications formerly 7029 1854 1958 319 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2896 2845 BellSouth.net Inc. 22773 2892 2751 Cox Communications Inc. 10620 2994 2749 Telmex Colombia S.A. 17974 2822 2745 PT Telekomunikasi Indonesia 7545 2389 2265 TPG Telecom Limited 4766 2946 2020 Korea Telecom 18566 2046 1864 MegaPath Corporation 6147 1801 1771 Telefonica del Peru S.A.A. 4755 1918 1729 TATA Communications formerly 9829 1652 1613 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:12 /10:30 /11:89 /12:261 /13:501 /14:1005 /15:1713 /16:13033 /17:7102 /18:11798 /19:24645 /20:35245 /21:37441 /22:55050 /23:47947 /24:275758 /25:1094 /26:1057 /27:710 /28:16 /29:19 /30:10 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2125 2892 Cox Communications Inc. 18566 2001 2046 MegaPath Corporation 6389 1676 2896 BellSouth.net Inc. 6147 1365 1801 Telefonica del Peru S.A.A. 30036 1323 1477 Mediacom Communications Corp 6983 1205 1516 ITC^Deltacom 11492 1145 1196 CABLE ONE, INC. 34984 1142 1822 TELLCOM ILETISIM HIZMETLERI A 7029 1140 1854 Windstream Communications Inc 8402 1119 1451 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1346 2:668 3:3 4:17 5:1165 6:21 8:761 12:1844 13:4 14:1144 15:17 16:2 17:42 18:21 20:51 23:942 24:1763 27:1818 31:1414 32:39 33:2 34:5 36:158 37:1779 38:1003 39:18 40:228 41:2956 42:257 43:471 44:17 45:81 46:2172 47:26 49:734 50:796 52:12 54:52 55:3 56:8 57:32 58:1212 59:644 60:434 61:1724 62:1254 63:1832 64:4384 65:2289 66:4221 67:2056 68:1052 69:3268 70:866 71:477 72:1992 74:2597 75:373 76:413 77:1604 78:1017 79:764 80:1329 81:1252 82:797 83:661 84:729 85:1350 86:453 87:1154 88:471 89:1790 90:138 91:5770 92:773 93:1670 94:2038 95:1302 96:428 97:340 98:1098 99:48 100:66 101:729 103:5821 104:450 105:140 106:188 107:647 108:578 109:1998 110:1045 111:1419 112:717 113:904 114:793 115:1182 116:1133 117:1048 118:1544 119:1352 120:458 121:974 122:2194 123:1639 124:1447 125:1512 128:616 129:354 130:362 131:909 132:430 133:165 134:325 135:78 136:321 137:292 138:379 139:192 140:222 141:407 142:598 143:417 144:505 145:110 146:691 147:557 148:996 149:378 150:504 151:721 152:474 153:240 154:358 155:564 156:376 157:330 158:278 159:945 160:324 161:602 162:1803 163:406 164:704 165:667 166:365 167:678 168:1123 169:122 170:1413 171:187 172:63 173:1633 174:708 175:617 176:1517 177:3620 178:2091 179:799 180:1748 181:1757 182:1663 183:628 184:707 185:2168 186:3001 187:1684 188:2143 189:1508 190:7868 191:777 192:7676 193:5536 194:4045 195:3605 196:1638 197:753 198:5273 199:5465 200:6462 201:2891 202:9149 203:9057 204:4698 205:2654 206:3023 207:2942 208:3931 209:3740 210:3307 211:1829 212:2366 213:2188 214:852 215:87 216:5600 217:1703 218:618 219:391 220:1371 221:703 222:484 223:599 End of report From johnl at iecc.com Fri Oct 10 18:21:29 2014 From: johnl at iecc.com (John Levine) Date: 10 Oct 2014 18:21:29 -0000 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: Message-ID: <20141010182129.2604.qmail@ary.lan> >But other than providing more warning, what would have been a better >way to start eliminating forged senders? Everything I've read >indicates that both Yahoo and AOL did this with eyes wide open. A good move would have been to improve their security so that AOL and Yahoo didn't have massive thefts of their customers' address book data (two separate times for one of them.) This meant that their users were getting large amounts of spam "from" people they knew, sent from outside of their networks. AOL and Yahoo made narrowly rational decisions to push the cost of their security failures onto the rest of the world. I understand why they did it, but that doesn't mean we have to like it, or to cut them any slack about it. R's, John From goemon at anime.net Fri Oct 10 18:27:25 2014 From: goemon at anime.net (goemon at anime.net) Date: Fri, 10 Oct 2014 11:27:25 -0700 (PDT) Subject: peer1 contact? In-Reply-To: <54381FA4.7000302@ninjabadger.net> References: <54381FA4.7000302@ninjabadger.net> Message-ID: On Fri, 10 Oct 2014, Tom Hill wrote: > On 10/10/14 19:01, Alistair Mackenzie wrote: >> Gmail gave me a warning about this email too so that may be your problem. > Yeah, my provider classified it as spam too (which I think is a fairly > basic SpamAssassin installation). nope. peer1 is rejecting emails on their end. ----- The following addresses had permanent fatal errors ----- (reason: 554 This message contains a virus (HTML/PayPal.EE) (Mode: normal)) ----- Transcript of session follows ----- ... while talking to peer1.com.inbound10.mxlogicmx.net.: >>> DATA <<< 554 This message contains a virus (HTML/PayPal.EE) (Mode: normal) 554 5.0.0 Service unavailable peer1 is making it impossible to report criminal scams originating directly from IP addresses under their direct control. peer1 - remove your filtering from your abuse@ mailbox. -Dan From list at satchell.net Fri Oct 10 19:10:33 2014 From: list at satchell.net (Stephen Satchell) Date: Fri, 10 Oct 2014 12:10:33 -0700 Subject: peer1 contact? In-Reply-To: References: <54381FA4.7000302@ninjabadger.net> Message-ID: <54382F29.8080108@satchell.net> What happens when you send plain-text mail, instead of HTML mail? On 10/10/2014 11:27 AM, goemon at anime.net wrote: > On Fri, 10 Oct 2014, Tom Hill wrote: >> On 10/10/14 19:01, Alistair Mackenzie wrote: >>> Gmail gave me a warning about this email too so that may be your >>> problem. >> Yeah, my provider classified it as spam too (which I think is a fairly >> basic SpamAssassin installation). > > nope. > > peer1 is rejecting emails on their end. > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 This message contains a virus (HTML/PayPal.EE) (Mode: > normal)) > > ----- Transcript of session follows ----- > ... while talking to peer1.com.inbound10.mxlogicmx.net.: >>>> DATA > <<< 554 This message contains a virus (HTML/PayPal.EE) (Mode: normal) > 554 5.0.0 Service unavailable > > > peer1 is making it impossible to report criminal scams originating > directly from IP addresses under their direct control. > > peer1 - remove your filtering from your abuse@ mailbox. > > -Dan From me at anuragbhatia.com Fri Oct 10 20:45:43 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 11 Oct 2014 02:15:43 +0530 Subject: astraceroute on MAC In-Reply-To: <20141010135157.GA13003@excession.tpb.net> References: <20141010135157.GA13003@excession.tpb.net> Message-ID: Dear Tim and Niels Surely default traceroute in MAC is there but the -a option isn't good. It picks data from RADB and not from actually visible prefix in global routing table. Hence wrongly registered RADB objects / old objects and more give weird output. E.g take example of trace to one of AS10029's IP's (the company I work for...) traceroute to 203.122.59.75 (203.122.59.75), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) [AS51167] 0.332 ms 0.348 ms 0.386 ms 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] 0.376 ms 0.368 ms 0.358 ms 3 xe-2-2-1.r3.muc2.m-online.net (212.18.6.81) [AS8767] 0.748 ms xe-2-0-1.r3.muc2.m-online.net (212.18.6.83) [AS8767] 0.639 ms xe-2-2-1.r3.muc2.m-online.net (212.18.6.81) [AS8767] 0.731 ms 4 DEMUE1IB03.de.en.vodafone.com (80.81.202.17) [AS51531/AS6695] 4.268 ms 4.246 ms 4.238 ms 5 85.205.25.114 (85.205.25.114) [AS3209/AS34419] 35.070 ms 35.009 ms 35.038 ms 6 145.253.33.238 (145.253.33.238) [AS3211] 32.247 ms 31.996 ms 33.534 ms 7 182.19.109.27 (182.19.109.27) [*] 168.699 ms 168.764 ms 168.794 ms 8 182.19.15.57 (182.19.15.57) [AS55410] 175.411 ms 175.283 ms 176.044 ms 9 203.122.61.148.reverse.spectranet.in (203.122.61.148) [AS10029/AS7722] 173.005 ms 172.216 ms 172.204 ms 10 * * * 11 * * * 12 * * * Here I am getting 203.122.61.148.reverse.spectranet.in (203.122.61.148) [AS10029/AS7722] in 9th hop. Now prefix is announced by AS10029 only but it shows AS7722 as well because there's a route object in RADB from Rivernet AS7722 in 2006. route: 203.122.61.0/24 descr: Rivernet origin: AS7722 mnt-by: MAINT-AS7474 changed: noc at optus.net.au 20060120 source: RADB I wish to see origin ASN of a prefix which is why looking for that tool. Thanks. On Fri, Oct 10, 2014 at 7:21 PM, Niels Bakker wrote: > * me at anuragbhatia.com (Anurag Bhatia) [Fri 10 Oct 2014, 14:59 CEST]: > >> Was wondering if anyone got the astraceroute tool working on MAC? >> > [..] > >> Does anyone knows any other alternate similar tool? >> > > Why bother when the supplied traceroute supports -a already? > > > -- Niels. > > -- > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From cidr-report at potaroo.net Fri Oct 10 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Oct 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201410102200.s9AM00uM077603@wattle.apnic.net> This report has been generated at Fri Oct 10 21:14:14 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-10-14 518176 287786 04-10-14 518633 287700 05-10-14 518571 287712 06-10-14 518483 287988 07-10-14 519132 288072 08-10-14 519152 288032 09-10-14 519388 288312 10-10-14 519407 288401 AS Summary 48513 Number of ASes in routing system 19559 Number of ASes announcing only one prefix 3029 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120100096 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 10Oct14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 519624 288264 231360 44.5% All ASes AS28573 3029 132 2897 95.6% NET Servi�os de Comunica��o S.A.,BR AS6389 2895 69 2826 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2822 83 2739 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2895 161 2734 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4766 2947 1208 1739 59.0% KIXS-AS-KR Korea Telecom,KR AS6147 1801 166 1635 90.8% Telefonica del Peru S.A.A.,PE AS7303 1776 286 1490 83.9% Telecom Argentina S.A.,AR AS9808 1534 46 1488 97.0% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1426 24 1402 98.3% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1916 645 1271 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1805 556 1249 69.2% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2403 1162 1241 51.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1644 413 1231 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1305 108 1197 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS10620 2994 1797 1197 40.0% Telmex Colombia S.A.,CO AS18566 2045 867 1178 57.6% MEGAPATH5-US - MegaPath Corporation,US AS7552 1207 61 1146 94.9% VIETEL-AS-AP Viettel Corporation,VN AS22561 1305 344 961 73.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS6983 1516 651 865 57.1% ITCDELTA - Earthlink, Inc.,US AS38285 954 123 831 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4788 1075 245 830 77.2% TMNET-AS-AP TM Net, Internet Service Provider,MY AS24560 1173 354 819 69.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS7029 1975 1184 791 40.1% WINDSTREAM - Windstream Communications Inc,US AS26615 915 130 785 85.8% Tim Celular S.A.,BR AS4780 1041 277 764 73.4% SEEDNET Digital United Inc.,TW AS18101 958 196 762 79.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS17908 838 92 746 89.0% TCISL Tata Communications,IN AS31148 1044 300 744 71.3% FREENET-AS Freenet Ltd.,UA AS8151 1489 753 736 49.4% Uninet S.A. de C.V.,MX Total 51726 12516 39210 75.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.220.173.0/24 AS30058 FDCSERVERS - FDCservers.net,US 91.228.160.0/24 AS19979 DEPO40-AS Trusov Ilya Igorevych,RU 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.157.184.0/22 AS12714 TI-AS Net By Net Holding LLC,RU 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 131.161.196.0/22 AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.210.240.0/24 AS17246 -Reserved AS-,ZZ 162.210.241.0/24 AS17246 -Reserved AS-,ZZ 162.210.244.0/24 AS17246 -Reserved AS-,ZZ 162.210.245.0/24 AS17246 -Reserved AS-,ZZ 162.210.246.0/24 AS17246 -Reserved AS-,ZZ 162.210.247.0/24 AS17246 -Reserved AS-,ZZ 162.244.140.0/24 AS17246 -Reserved AS-,ZZ 162.244.141.0/24 AS17246 -Reserved AS-,ZZ 162.244.142.0/24 AS17246 -Reserved AS-,ZZ 162.244.143.0/24 AS17246 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 cidr-report at potaroo.net Fri Oct 10 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Oct 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201410102200.s9AM019K077616@wattle.apnic.net> BGP Update Report Interval: 02-Oct-14 -to- 09-Oct-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7552 1489150 21.8% 1181.9 -- VIETEL-AS-AP Viettel Corporation,VN 2 - AS23752 195100 2.9% 2217.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS31148 189245 2.8% 181.8 -- FREENET-AS Freenet Ltd.,UA 4 - AS38623 178026 2.6% 1271.6 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 5 - AS9829 175788 2.6% 168.5 -- BSNL-NIB National Internet Backbone,IN 6 - AS34984 102829 1.5% 134.8 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 7 - AS13682 85660 1.2% 9517.8 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 8 - AS3816 72512 1.1% 106.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 9 - AS38197 69916 1.0% 77.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 10 - AS25374 60996 0.9% 423.6 -- ESCOMBG-AS ESCOM Ltd. - Haskovo,BG 11 - AS21415 48053 0.7% 410.7 -- INTERNETGROUP-AS-BG Internet Group Ltd.,BG 12 - AS8877 47360 0.7% 238.0 -- POWERNET-AS Telehouse EAD,BG 13 - AS29084 42712 0.6% 318.7 -- COMNET-AS Comnet Bulgaria Holding Ltd.,BG 14 - AS8402 39701 0.6% 65.6 -- CORBINA-AS OJSC "Vimpelcom",RU 15 - AS15471 38539 0.6% 303.5 -- SNR-RO S.N. Radiocomunicatii S.A.,RO 16 - AS28573 35446 0.5% 27.6 -- NET Servi�os de Comunica��o S.A.,BR 17 - AS39184 34060 0.5% 266.1 -- ULTRANET-AS ,BG 18 - AS29582 31968 0.5% 247.8 -- SATCOM-AS Optisprint,BG 19 - AS45899 31247 0.5% 66.9 -- VNPT-AS-VN VNPT Corp,VN 20 - AS12302 30646 0.5% 281.2 -- VODAFONE_RO Vodafone Romania S.A.,RO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23342 22138 0.3% 22138.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 2 - AS25003 19539 0.3% 19539.0 -- INTERNET_BINAT Internet Binat Ltd,IL 3 - AS2 11590 0.2% 661.0 -- UDEL-DCN - University of Delaware,US 4 - AS13682 85660 1.2% 9517.8 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 5 - AS18135 9374 0.1% 9374.0 -- BTV BTV Cable television,JP 6 - AS60599 3982 0.1% 3982.0 -- WEBKOMPAS-AS Emelyanov Valentin Petrovich,RU 7 - AS47887 7303 0.1% 3651.5 -- NEU-AS AL-HADATHEH LIL-ITISALAT WA AL-TECHNOLOGIA CO.,JO 8 - AS51888 3626 0.1% 3626.0 -- PILOTSYSTEMS-AS Pilot Systems consulting SARL,FR 9 - AS62174 3389 0.1% 3389.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS53191 22207 0.3% 3172.4 -- PLUGNET Tecnologia e Informatica LTDA,BR 11 - AS23752 195100 2.9% 2217.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 12 - AS4 2205 0.0% 490.0 -- ISI-AS - University of Southern California,US 13 - AS45606 10931 0.2% 2186.2 -- 14 - AS8738 2013 0.0% 2013.0 -- VISA-ISRAEL-AS Israel Credit Cards Ltd,IL 15 - AS6629 9838 0.1% 1967.6 -- NOAA-AS - NOAA,US 16 - AS52729 3855 0.1% 1927.5 -- BrNet Informatica,BR 17 - AS3 1632 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS19213 3170 0.1% 1585.0 -- SABRE-DFW - Sabre Inc.,US 19 - AS30944 1575 0.0% 1575.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 20 - AS55917 1549 0.0% 1549.0 -- IYOGI-IN Building No:6 Tower C FF,IN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 97982 1.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 96205 1.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 64.29.130.0/24 22138 0.3% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 4 - 192.115.44.0/22 19539 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 5 - 200.119.160.0/19 16677 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 6 - 190.143.240.0/20 16657 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 7 - 190.143.192.0/19 14143 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 8 - 190.143.224.0/20 14088 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 9 - 200.119.152.0/21 14008 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 10 - 103.15.143.0/24 11859 0.2% AS2 -- UDEL-DCN - University of Delaware,US AS58495 -- HSPNET-AS-ID PT Parsaoran Global Datatrans,ID 11 - 200.34.149.0/24 11849 0.2% AS8151 -- Uninet S.A. de C.V.,MX 12 - 200.119.150.0/23 10075 0.1% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 13 - 192.58.232.0/24 9815 0.1% AS6629 -- NOAA-AS - NOAA,US 14 - 42.83.48.0/20 9374 0.1% AS18135 -- BTV BTV Cable television,JP 15 - 188.123.160.0/19 7302 0.1% AS47887 -- NEU-AS AL-HADATHEH LIL-ITISALAT WA AL-TECHNOLOGIA CO.,JO 16 - 41.221.20.0/24 7012 0.1% AS36947 -- ALGTEL-AS,DZ 17 - 204.140.216.0/24 5442 0.1% AS226 -- LOS-NETTOS-AS - Los Nettos,US 18 - 84.205.66.0/24 4865 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 19 - 189.50.136.0/23 4667 0.1% AS28330 -- IFTNET Informatica Ltda,BR 20 - 177.8.216.0/24 4554 0.1% AS53191 -- PLUGNET Tecnologia e Informatica LTDA,BR 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 rsk at gsp.org Fri Oct 10 22:19:27 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 10 Oct 2014 18:19:27 -0400 Subject: Bounce action notifications - NANOG mailing list changes yahoo.com users In-Reply-To: References: <20141009222011.GK7948@bucket.gawul.net> <20141010142848.GA2994@gsp.org> <5438042C.30700@mtcc.com> Message-ID: <20141010221927.GA9739@gsp.org> On Fri, Oct 10, 2014 at 09:48:26PM +0530, Suresh Ramasubramanian wrote: > Call it triage. When a minuscule amount of mailing list traffic is weighed > against huge volumes of forged spam and phish... Triage as an abuse mitigation tactic is fine. But where that triage needs to be applied, and where it can be most effective, is at the *source* of the abuse. Which is not here or any other of the myriad mailing lists where most of the heavy lifting is done WRT to networking, security, software and all the other things that make the 'net work. Yahoo itself is a major source of abuse, it has been for many years, and there is absolutely no visible sign that they've done anything about it, that they're doing anything about it, or that they intend to do anything about it. Spam/phishes show up all day, every day, and yes they really *are* from Yahoo, so there's not much need at the moment for anyone to bother forging an @yahoo address. (That's kind of like creating an exquisitely detailed fake replica of a Mercedes-Benz sedan and then slapping a Yugo logo on it. Why would any forger good enough to pull that off devalue their own effort by deliberately associating it with junk?) So please, let's not pretend that Yahoo has suddenly had a come-to-Jebus moment and is interested in stopping abuse. They're not. If they were, they would have invested resources into their own operation many years ago, they would deal with their abuse@ email promptly and professionally, and Yahoo-sourced abuse would be an isolated/transient problem, rather than a systemic/persistent one. What they *are* interested in, given the floundering state of their company, is anything they can do to retain users -- and screwing up others' mailing lists (for which the operators are being blamed, through no fault of their own) in favor of their own offerings is one way to achieve that. ---rsk From faisal at snappytelecom.net Sat Oct 11 05:41:43 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 11 Oct 2014 05:41:43 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> Message-ID: <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> A follow up question on this topic.. For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? (the BCOP document suggests this, but does not offer any explanation or merits of one over the other). Regards. Faisal Imtiaz Snappy Internet & Telecom From rdobbins at arbor.net Sat Oct 11 06:00:21 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 11 Oct 2014 13:00:21 +0700 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: On Oct 11, 2014, at 12:41 PM, Faisal Imtiaz wrote: > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? In the BCOP, this is noted so that those who suboptimally address their p-t-p links with /64s can be consistently suboptimal by doing the same with their loopbacks, so that *all* their interfaces are sinkholes. But the BCOP also talks about /128s. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From mansaxel at besserwisser.org Sat Oct 11 06:03:32 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 11 Oct 2014 08:03:32 +0200 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141011060331.GB29165@besserwisser.org> Subject: Re: IPv6 Default Allocation - What size allocation for Loopback Address Date: Sat, Oct 11, 2014 at 05:41:43AM +0000 Quoting Faisal Imtiaz (faisal at snappytelecom.net): > A follow up question on this topic.. > > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? > (the BCOP document suggests this, but does not offer any explanation or merits of one over the other). I use a /128 -- these addresses are going to be used de-aggregated in the IGP only; outside they are part of your aggregated allocation. Then again; I'm using /127 on links. Just because it is a tad easier to do dual-stack on the scripts that build the config. And, I get to have all my links in 2001:0db8:f00:feed:dada::/80 :-) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm thinking about DIGITAL READ-OUT systems and computer-generated IMAGE FORMATIONS ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From faisal at snappytelecom.net Sat Oct 11 06:33:11 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 11 Oct 2014 06:33:11 +0000 (GMT) Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> > In the BCOP, this is noted so that those who suboptimally address their p-t-p > links with /64s can be consistently suboptimal by doing the same with their > loopbacks, I am trying to understand what is sub-optimal about doing so...Waste of Ipv6 space ? or some other technical reason ? (is a /64 address are a 'sinkhole' the only reason ? ) Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Roland Dobbins" > To: "nanog at nanog.org list" > Sent: Saturday, October 11, 2014 2:00:21 AM > Subject: Re: IPv6 Default Allocation - What size allocation for Loopback Address > > > On Oct 11, 2014, at 12:41 PM, Faisal Imtiaz wrote: > > > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 > > ? > > In the BCOP, this is noted so that those who suboptimally address their p-t-p > links with /64s can be consistently suboptimal by doing the same with their > loopbacks, so that *all* their interfaces are sinkholes. > > But the BCOP also talks about /128s. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > > From rdobbins at arbor.net Sat Oct 11 06:37:28 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 11 Oct 2014 13:37:28 +0700 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> Message-ID: On Oct 11, 2014, at 1:33 PM, Faisal Imtiaz wrote: > I am trying to understand what is sub-optimal about doing so...Waste of Ipv6 space ? or some other technical reason ? It's wasteful of address space, but more importantly, it turns your router into a sinkole. > (is a /64 address are a 'sinkhole' the only reason ? ) That's a pretty big reason not to use /64s. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From ler762 at gmail.com Sat Oct 11 15:52:25 2014 From: ler762 at gmail.com (Lee) Date: Sat, 11 Oct 2014 11:52:25 -0400 Subject: IPv6 Default Allocation - What size allocation are you giving out In-Reply-To: <54376DD4.2040800@fud.no> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <20141009013115.CDFBF2116E22@rock.dv.isc.org> <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu> <20141009092914.A04CE213074C@rock.dv.isc.org> <54366AB9.3040504@gmail.com> <20141009135658.EF0432132042@rock.dv.isc.org> <0AB5689E-6AAF-44FF-9C12-A40FEB62C407@delong.com> <54376DD4.2040800@fud.no> Message-ID: On 10/10/14, Tore Anderson wrote: > * Baldur Norddahl > >> Why do people assign addresses to point-to-point links at all? You can just >> use a host /128 route to the loopback address of the peer. Saves you the >> hassle of coming up with new addresses for every link. Some people think the benefit is worth the hassle. > Why do you need those host routes? network management, logging, troubleshooting.. you need at least one loopback with a global address. > Most IPv6 IGPs work just fine without global addresses or host routes. > > https://tools.ietf.org/html/draft-ietf-opsec-lla-only-11 Look at the discussion of the draft - there seemed >>to me<< a clear consensus that using only link local addressing was a Bad Idea. I thought the caveats section made the draft worth publishing, but this bit was left out: And while the caveats hint at it, there's also an operational complexity burden that isn't called out - the ping and NMS/discovery limitations also apply to human operators troubleshooting faults and attempting to understand a deployed topology. LLDP and NDP add a layer of indirection in identifying what devices should be adjacent to a given interface, and only work when there is operational state available and links are up (whereas GUAs on interconnected devices can be compared by configuration alone, telling you what's supposed to be there). Erik Muller so the draft isn't as clear as I'd hoped regarding the caveats :( Best Regards, Lee From geier at geier.ne.tz Sat Oct 11 16:47:29 2014 From: geier at geier.ne.tz (Frank Habicht) Date: Sat, 11 Oct 2014 19:47:29 +0300 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: <54395F21.6080501@geier.ne.tz> On 10/11/2014 8:41 AM, Faisal Imtiaz wrote: > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? The number of IPs addresses used on them subnets on them loopbacks is as far as I can foresee only one [for each loopback]. So a subnet of size "one address" should do it. And that seems to be the same in v4 and v6 Frank From mansoor.nathani at mnathani.com Fri Oct 10 21:30:16 2014 From: mansoor.nathani at mnathani.com (Mansoor Nathani) Date: Fri, 10 Oct 2014 17:30:16 -0400 Subject: astraceroute on MAC In-Reply-To: References: <20141010135157.GA13003@excession.tpb.net> Message-ID: Hi Anurag Here is sample output from using the mtr command: the -z flag shows AS Numbers however, I am not sure where they come from or are looked up. mtr can be downloaded : https://code.google.com/p/rudix/downloads/detail?name=mtr-0.82-0.pkg mtr -4z google.com x61 (0.0.0.0) Fri Oct 10 17:24:21 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 10.10.10.10 0.0% 4 0.3 0.4 0.3 0.6 0.0 2. AS??? 7.207.122.129 0.0% 4 8.3 7.1 6.5 8.3 0.6 3. AS812 209.148.245.53 0.0% 4 8.8 10.0 8.8 11.1 1.0 4. AS812 24.153.5.233 0.0% 3 8.8 10.2 8.8 11.5 1.0 5. AS5645 ae0_2140-bdr04-tor.teksavvy.com 0.0% 3 12.6 12.1 10.2 13.6 1.6 6. AS15169 72.14.212.134 0.0% 3 10.4 9.7 8.2 10.4 1.0 7. AS15169 216.239.47.114 0.0% 3 10.1 9.9 9.5 10.2 0.0 8. AS15169 209.85.250.207 0.0% 3 9.5 11.0 9.5 12.9 1.6 9. AS15169 yyz08s13-in-f2.1e100.net 0.0% 3 9.7 9.8 9.2 10.3 0.0 And to your IP: mtr -z 203.122.59.75 x61 (0.0.0.0) Fri Oct 10 17:26:32 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 10.10.10.10 0.0% 6 0.3 0.3 0.2 0.6 0.0 2. AS??? 7.207.122.129 0.0% 6 8.2 9.0 7.5 14.4 2.6 3. AS812 209.148.245.53 0.0% 6 14.0 14.6 10.7 21.0 3.7 4. AS812 24.153.5.233 0.0% 6 7.9 9.5 7.9 10.5 1.0 5. AS5645 ae0_2140-bdr04-tor.teksavvy.com 0.0% 6 9.8 9.5 8.0 10.2 0.6 6. AS6453 ix-0-0-2-0.tcore1.tnk-toronto.as6453.net 0.0% 6 9.4 11.2 9.0 18.8 3.7 7. AS6453 if-5-0-0-5.core4.tnk-toronto.as6453.net 0.0% 6 11.2 11.1 9.7 15.0 1.9 8. AS6453 if-2-3-2-0.tcore1.ct8-chicago.as6453.net 0.0% 6 118.5 118.7 117.2 122.0 1.8 9. AS6453 if-12-6.tcore2.nyy-new-york.as6453.net 80.0% 6 118.8 118.8 118.8 118.8 0.0 10. AS6453 if-20-2.tcore2.l78-london.as6453.net 0.0% 6 120.2 116.6 112.9 120.2 3.2 11. AS6453 80.231.131.66 0.0% 6 227.5 228.4 227.5 229.5 0.7 12. AS??? 172.29.252.34 0.0% 6 279.2 278.8 277.9 279.2 0.0 13. AS4755 14.141.116.30.static-delhi.vsnl.net.in 0.0% 5 246.0 244.6 243.6 246.0 0.7 14. AS10029 203.122.61.148.reverse.spectranet.in 0.0% 5 246.1 247.7 246.1 249.8 1.5 15. ??? 16. ??? 17. AS10029 jane.spectranet.in 0.0% 5 247.7 249.1 246.5 257.3 4.6 Mansoor On Fri, Oct 10, 2014 at 4:45 PM, Anurag Bhatia wrote: > Dear Tim and Niels > > > Surely default traceroute in MAC is there but the -a option isn't good. It > picks data from RADB and not from actually visible prefix in global routing > table. Hence wrongly registered RADB objects / old objects and more give > weird output. > > E.g take example of trace to one of AS10029's IP's (the company I work > for...) > > > traceroute to 203.122.59.75 (203.122.59.75), 30 hops max, 60 byte packets > 1 gw.giga-dns.com (91.194.90.1) [AS51167] 0.332 ms 0.348 ms 0.386 ms > 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] > 0.376 ms 0.368 ms 0.358 ms > 3 xe-2-2-1.r3.muc2.m-online.net (212.18.6.81) [AS8767] 0.748 ms > xe-2-0-1.r3.muc2.m-online.net (212.18.6.83) [AS8767] 0.639 ms > xe-2-2-1.r3.muc2.m-online.net (212.18.6.81) [AS8767] 0.731 ms > 4 DEMUE1IB03.de.en.vodafone.com (80.81.202.17) [AS51531/AS6695] 4.268 > ms > 4.246 ms 4.238 ms > 5 85.205.25.114 (85.205.25.114) [AS3209/AS34419] 35.070 ms 35.009 ms > 35.038 ms > 6 145.253.33.238 (145.253.33.238) [AS3211] 32.247 ms 31.996 ms 33.534 > ms > 7 182.19.109.27 (182.19.109.27) [*] 168.699 ms 168.764 ms 168.794 ms > 8 182.19.15.57 (182.19.15.57) [AS55410] 175.411 ms 175.283 ms 176.044 > ms > 9 203.122.61.148.reverse.spectranet.in (203.122.61.148) [AS10029/AS7722] > 173.005 ms 172.216 ms 172.204 ms > 10 * * * > 11 * * * > 12 * * * > > > > Here I am getting 203.122.61.148.reverse.spectranet.in (203.122.61.148) > [AS10029/AS7722] in 9th hop. Now prefix is announced by AS10029 only but it > shows AS7722 as well because there's a route object in RADB from Rivernet > AS7722 in 2006. > > > route: 203.122.61.0/24 > descr: Rivernet > origin: AS7722 > mnt-by: MAINT-AS7474 > changed: noc at optus.net.au 20060120 > source: RADB > > > > I wish to see origin ASN of a prefix which is why looking for that tool. > > > Thanks. > > On Fri, Oct 10, 2014 at 7:21 PM, Niels Bakker > wrote: > > > * me at anuragbhatia.com (Anurag Bhatia) [Fri 10 Oct 2014, 14:59 CEST]: > > > >> Was wondering if anyone got the astraceroute tool working on MAC? > >> > > [..] > > > >> Does anyone knows any other alternate similar tool? > >> > > > > Why bother when the supplied traceroute supports -a already? > > > > > > -- Niels. > > > > -- > > > > > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | Twitter > > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > From raphael.timothy at gmail.com Sat Oct 11 07:09:08 2014 From: raphael.timothy at gmail.com (Tim Raphael) Date: Sat, 11 Oct 2014 15:09:08 +0800 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> Message-ID: <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces. This makes a lot of sense to me as (which has been said) there is no other *need* in the foreseeable future to have more than one IP on the loopback - this is the purpose of it. Any technology or design that requires this has got scaling issues and should not be used anyway. Regards, Tim Raphael > On 11 Oct 2014, at 2:37 pm, Roland Dobbins wrote: > > >> On Oct 11, 2014, at 1:33 PM, Faisal Imtiaz wrote: >> >> I am trying to understand what is sub-optimal about doing so...Waste of Ipv6 space ? or some other technical reason ? > > It's wasteful of address space, but more importantly, it turns your router into a sinkole. > >> (is a /64 address are a 'sinkhole' the only reason ? ) > > That's a pretty big reason not to use /64s. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > From rdobbins at arbor.net Sat Oct 11 21:00:30 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 12 Oct 2014 04:00:30 +0700 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> Message-ID: <3D7B3680-BB82-412B-82AF-5664E48AAD84@arbor.net> On Oct 11, 2014, at 2:09 PM, Tim Raphael wrote: > From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces. Yes, this is what I advocate for loopbacks. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From nmaxpierson at gmail.com Sat Oct 11 21:49:44 2014 From: nmaxpierson at gmail.com (N. Max Pierson) Date: Sat, 11 Oct 2014 16:49:44 -0500 Subject: Charter Communications Contact Message-ID: Can someone from Charter Communications engineering/support hit me up off list please? Sorry for the noise. Regards, Max From khomyakov.andrey at gmail.com Sat Oct 11 22:05:57 2014 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Sat, 11 Oct 2014 18:05:57 -0400 Subject: AT&T AVPN BGP Communities Message-ID: paging AT&T peeps Does anyone have AT&T's AVPN BGP communities reference guide? e.g. 13979:120 to set local_pref to 120 and so on. Thanks in advance! --Andrey From jhma at mcvax.org Sun Oct 12 08:58:02 2014 From: jhma at mcvax.org (James Aldridge) Date: Sun, 12 Oct 2014 09:58:02 +0100 Subject: astraceroute on MAC In-Reply-To: References: <20141010135157.GA13003@excession.tpb.net> Message-ID: <543A429A.10805@mcvax.org> On 10/10/2014 22:30, Mansoor Nathani wrote: > Hi Anurag > > Here is sample output from using the mtr command: the -z flag shows AS > Numbers however, I am not sure where they come from or are looked up. It appears to be using the Team Cymru service - http://www.team-cymru.org/Services/ip-to-asn.html > mtr can be downloaded : > https://code.google.com/p/rudix/downloads/detail?name=mtr-0.82-0.pkg ... or as part of MacPorts Regards, James From sander at steffann.nl Sun Oct 12 12:53:36 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 12 Oct 2014 14:53:36 +0200 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <3D7B3680-BB82-412B-82AF-5664E48AAD84@arbor.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> <3D7B3680-BB82-412B-82AF-5664E48AAD84@arbor.net> Message-ID: <0BB78C39-5E3A-44B8-B2C7-C044C9641393@steffann.nl> Hi, > Op 11 okt. 2014, om 23:00 heeft Roland Dobbins het volgende geschreven: > >> On Oct 11, 2014, at 2:09 PM, Tim Raphael wrote: >> >>> From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces. >> >> Yes, this is what I advocate for loopbacks. I often use the first /64 for loopbacks. Loopbacks are often used for management, iBGP etc and having short and easy to read addresses can be helpful. Something like 2001:db8::1 is easier to remember and type correctly than e.g. 2001:db8:18ba:ff42::1 :) Cheers, Sander From morrowc.lists at gmail.com Sun Oct 12 14:35:47 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 12 Oct 2014 10:35:47 -0400 Subject: AT&T AVPN BGP Communities In-Reply-To: References: Message-ID: presumably you looked at charlie's site already? http://onesc.net/communities/ On Sat, Oct 11, 2014 at 6:05 PM, Andrey Khomyakov wrote: > paging AT&T peeps > > Does anyone have AT&T's AVPN BGP communities reference guide? > e.g. 13979:120 to set local_pref to 120 and so on. > > Thanks in advance! > > --Andrey From rcarpen at network1.net Sun Oct 12 16:54:58 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 12 Oct 2014 12:54:58 -0400 (EDT) Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1292998589.649182.1413132893611.JavaMail.zimbra@network1.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> <3D7B3680-BB82-412B-82AF-5664E48AAD84@arbor.net> <0BB78C39-5E3A-44B8-B2C7-C044C9641393@steffann.nl> Message-ID: <521685298.649183.1413132898036.JavaMail.zimbra@network1.net> ----- On Oct 12, 2014, at 8:53 AM, Sander Steffann sander at steffann.nl wrote: > Hi, > >> Op 11 okt. 2014, om 23:00 heeft Roland Dobbins het volgende >> geschreven: >> >>> On Oct 11, 2014, at 2:09 PM, Tim Raphael wrote: >>> >>>> From my research, various authorities have recommended that a single /64 be >>>> allocated to router loopbacks with /128s assigned on interfaces. >>> >>> Yes, this is what I advocate for loopbacks. > > I often use the first /64 for loopbacks. Loopbacks are often used for > management, iBGP etc and having short and easy to read addresses can be > helpful. Something like 2001:db8::1 is easier to remember and type correctly > than e.g. 2001:db8:18ba:ff42::1 :) > > Cheers, > Sander I concur. I think think some have gotten confused with the suggesting of allocating a /64 for *ALL* loopbacks versus allocating a full /64 per loopback. Loopbacks should be /128, but all loopbacks for a site should be within a single /64 (the first one for reasons others, including Sander have said. -Randy From bill at herrin.us Sun Oct 12 22:00:57 2014 From: bill at herrin.us (William Herrin) Date: Sun, 12 Oct 2014 18:00:57 -0400 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: On Sat, Oct 11, 2014 at 1:41 AM, Faisal Imtiaz wrote: > A follow up question on this topic.. > > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? > (the BCOP document suggests this, but does not offer any explanation or merits of one over the other). Hi Faisal, One of the viewpoints held by some in the IETF is that an IPv6 address is not 128 bits. Rather, it is 64 bits of network space and 64 bits of host space. I'm told this viewpoint is responsible for the existence of a 128 bit address instead of IPv6 using 64 bit addresses. If you follow that reasoning, the subnet mask should always be /64, no matter where the address is assigned. There are, of course, excellent operational reasons not to religiously follow that plan. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From jra at baylink.com Sun Oct 12 22:06:17 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 12 Oct 2014 18:06:17 -0400 (EDT) Subject: large BCP38 compliance testing In-Reply-To: <54328BF8.3080907@pubnix.net> Message-ID: <8595580.5245.1413151577472.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alain Hebert" > > Gee, Alain... > > > > where would people find a wiki like that? > > On google maybe... > > I see someone is already squatting http://www.bcp38.info :( > ( /end_of_friday_silliness ) [ For those who were not playing the home game, Alain and I *run* bcp38.info, with... a little less help from the community than we were hoping for. :-) ] Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From joelja at bogus.com Sun Oct 12 22:44:17 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 12 Oct 2014 15:44:17 -0700 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: <543B0441.7020900@bogus.com> On 10/12/14 3:00 PM, William Herrin wrote: > On Sat, Oct 11, 2014 at 1:41 AM, Faisal Imtiaz wrote: >> A follow up question on this topic.. >> >> For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? >> (the BCOP document suggests this, but does not offer any explanation or merits of one over the other). > > Hi Faisal, > > One of the viewpoints held by some in the IETF is that an IPv6 address > is not 128 bits. Rather, it is 64 bits of network space and 64 bits of > host space. I'm told this viewpoint is responsible for the existence > of a 128 bit address instead of IPv6 using 64 bit addresses. > > If you follow that reasoning, the subnet mask should always be /64, no > matter where the address is assigned. https://tools.ietf.org/html/rfc6164 Is a standards track document. it is imho a repudiation of the assumptions about the dimensions of the host field. > There are, of course, excellent operational reasons not to religiously > follow that plan. > > Regards, > Bill Herrin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From jra at baylink.com Sun Oct 12 23:09:36 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 12 Oct 2014 19:09:36 -0400 Subject: Netalyzr Android: call for volunteers In-Reply-To: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> References: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> Message-ID: <39812359-ca1e-48fe-9492-92ee8622104c@email.android.com> Is spiffy... but any chance that you could add testing for intermediate carrier BCP 38 compliance? On October 5, 2014 6:43:31 PM EDT, Srikanth Sundaresan wrote: >Hi all, > >Netalyzr is a free network measurement and debugging app developed >by the International Computer Science Institute, Berkeley. > >It is designed to check for a wide range of network problems and >neutrality >violations, including unadvertised port filtering, DNS wildcarding, and > >hidden proxy servers. Our browser applet has more than a million runs. > >Netalyzr for Android was released in October 2013. We are happy to >announce a new release that has new tests for better middlebox >probing and a better UI. > >If you're interested, you can download and run the app from >Google Play [1]. If you already have the app, please consider >updating and re-running it - it would be very helpful for us to >capture updates regarding how the mobile Internet is evolving. > >Oh and: please consider watching our talk at NANOG 62 on Monday [2]! > >Thanks, >The Netalyzr Team. > >[1] >https://play.google.com/store/apps/details?id=edu.berkeley.icsi.netalyzr.android&hl=en >[2] https://www.nanog.org/meetings/abstract?id=2419 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From marka at isc.org Mon Oct 13 00:04:34 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 13 Oct 2014 11:04:34 +1100 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: Your message of "Sun, 12 Oct 2014 18:00:57 -0400." References: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads> <29886F49-E7D5-410F-BC26-0E64FE942AED@arbor.net> <73D241E1-3B18-4B17-85C1-FFA96C7EC95D@arbor.net> <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> Message-ID: <20141013000434.9930A214CAA3@rock.dv.isc.org> In message , William Herrin writes: > On Sat, Oct 11, 2014 at 1:41 AM, Faisal Imtiaz wrote: > > A follow up question on this topic.. > > > > For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? > > (the BCOP document suggests this, but does not offer any explanation or merits of one over the other). > > Hi Faisal, > > One of the viewpoints held by some in the IETF is that an IPv6 address > is not 128 bits. Rather, it is 64 bits of network space and 64 bits of > host space. I'm told this viewpoint is responsible for the existence > of a 128 bit address instead of IPv6 using 64 bit addresses. IPNG looked at 48 bits, 64 bits and 128 bits addresses. 48 and 64 bits would both have left everyone tightly managing subnet sizes and allocation sizes like we do in IPv4. IPv6 went to 128 bits to *allow* for a 64/64 split eventually where one didn't have to tightly manage subnet sizes and allocations. Earlier plans looked at 48 bits for the subnet size based in Ethernet MAC. It went to 64 bits with 48 bit MAC's padded to 64 bits to account for 64 bit MAC's and because a 64/64 split would possibly be more efficient / simpler. No one was making it a hard split at the time. > If you follow that reasoning, the subnet mask should always be /64, no > matter where the address is assigned. > > There are, of course, excellent operational reasons not to religiously > follow that plan. > > Regards, > Bill Herrin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From saper at saper.info Mon Oct 13 01:26:36 2014 From: saper at saper.info (Marcin Cieslak) Date: Mon, 13 Oct 2014 01:26:36 +0000 (UTC) Subject: Netalyzr Android: call for volunteers In-Reply-To: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> References: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> Message-ID: On Sun, 5 Oct 2014, Srikanth Sundaresan wrote: > If you're interested, you can download and run the app from > Google Play [1]. > > [1] https://play.google.com/store/apps/details?id=edu.berkeley.icsi.netalyzr.android&hl=en For those few who use Android (Cyanogenmod) and opt out of using Google services, is a direct .apk download available somewhere? If the app itself is open source, .apk could be provided by the alternative markets such as fdroid.org //Marcin From erey at ernw.de Mon Oct 13 07:52:46 2014 From: erey at ernw.de (Enno Rey) Date: Mon, 13 Oct 2014 09:52:46 +0200 Subject: IPv6 Default Allocation - What size allocation for Loopback Address In-Reply-To: <0BB78C39-5E3A-44B8-B2C7-C044C9641393@steffann.nl> References: <72063A0A-BF3E-4D68-9492-D6593E85AD2A@arbor.net> <1070171971.148616.1413006103313.JavaMail.zimbra@snappytelecom.net> <1692884369.149117.1413009191366.JavaMail.zimbra@snappytelecom.net> <33B2DBCF-1B13-4DEE-9D84-4A22F5AFBBB8@gmail.com> <3D7B3680-BB82-412B-82AF-5664E48AAD84@arbor.net> <0BB78C39-5E3A-44B8-B2C7-C044C9641393@steffann.nl> Message-ID: <20141013075246.GN8866@ernw.de> Hi, On Sun, Oct 12, 2014 at 02:53:36PM +0200, Sander Steffann wrote: > Hi, > > > Op 11 okt. 2014, om 23:00 heeft Roland Dobbins het volgende geschreven: > > > >> On Oct 11, 2014, at 2:09 PM, Tim Raphael wrote: > >> > >>> From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces. > >> > >> Yes, this is what I advocate for loopbacks. > > I often use the first /64 for loopbacks. I'm not a big fan of using all-zero third or fourth quarters of $PREFIX at all (at least not if one follows RFC 5952 & uses static, short IIDs, which will be case for loopbacks). On a crowded visio diagram it might not be easy to spot that 2001:db8::1, 2001:db8:0:1::1, 2001:db8:1::1 and 2001:db8:1:1::1 are all different addresses, potentially on the same hierarchy level. Hence we prefer to use FFFF or just FF "at some point within the prefix" for loopbacks, e.g. 2001:db8:FF::1 etc. best Enno Loopbacks are often used for management, iBGP etc and having short and easy to read addresses can be helpful. Something like 2001:db8::1 is easier to remember and type correctly than e.g. 2001:db8:18ba:ff42::1 :) > > Cheers, > Sander > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From galvao at nic.br Mon Oct 13 15:10:13 2014 From: galvao at nic.br (Antonio Galvao de Rezende Filho) Date: Mon, 13 Oct 2014 12:10:13 -0300 Subject: PTT.br / PTTForum 8 - Brazil Internet Exchange Forum - Call for presentations Message-ID: <543BEB55.5080502@nic.br> We invite PTT.br IXP Members, Autonomous Systems, the Internet community and Vendors to submit proposals for presentations at PTTForum 8 to be held at São Paulo(Hotel Blue Tree Morumbi) on November 24 - 25, 2014 on topics of Brazilian Internet community interest and improvement of Internet services in Brazil, as well as suggestions for new discussion topics related to Internet Exchange Points. The PTTForum 8 edition happens during the 4nd Week of Internet Infrastructure in Brazil, in conjunction with the 5rd IPv6 Forum and GTER 38 (Network engineering and operation work group) / GTS 24 (Network security work group) . Schedule for the selection: . Deadline for proposals reception: *24 October 2014* . Notification of proposal acceptance: *31 October 2014* . Deadline for the submission of final versions: *10 November 2014* Those interested in presenting their work, should send the following data, within the timeframe specified above, to the following address: pttforum at ptt.br . Complete title of the presentation. . Extended abstract plus a draft of the slides or the complete article if it were available. . Complete name(s), email address(es), biographical data and organization(s) of which the interested parties are part of or represent. . Estimated Time -- Galvao Rezende +55 11 5509-3524 +55 11 99946-5096 INOC-DBA: 22548*247 PTT.br - http://ptt.br/ NIC.br - http://nic.br/ From jcurran at arin.net Mon Oct 13 20:22:32 2014 From: jcurran at arin.net (John Curran) Date: Mon, 13 Oct 2014 20:22:32 +0000 Subject: IANA Stewardship Transition Proposal - Issue survey and ARIN-region Mailing List References: <543C2A48.9080604@arin.net> Message-ID: <3E33E1F7-2ABA-4B9D-83AC-13F0A2763703@corp.arin.net> NANOGers - If you are interested in the evolution of the stewardship over the Internet Assigned Numbers Authority (IANA), then please take a moment to complete the survey noted in the attached announcement and subscribe to the iana-stewardship at arin.net mailing list. The survey results and discussion on that mailing list will be used to formulate a proposal from the ARIN region (to be combined with the other regions) for transition of the IANA stewardship. Reference the ICANN announcement for more background. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] IANA Stewardship Transition Proposal Survey and Mailing List Date: October 13, 2014 at 12:38:48 PM PDT To: > * Cross-posted to arin-announce and arin-consult. As a part of the Regional Internet Registry (RIR) system, the ARIN community has been called to contribute to the ongoing global multistakeholder discussion on the IANA Stewardship Transition. The feedback from the ARIN community will be part of the contribution provided by the Number Resource Organization (NRO) to the IANA Stewardship Transition Coordination Group (ICG) in response to their recent “Request for Proposals (RFP) for ‭IANA‬ Stewardship Transition Proposal‬. ‬‬‬” https://www.icann.org/news/announcement-3-2014-09-03-en We would also like your opinion on number of specific points detailed in a short survey at: https://www.surveymonkey.com/s/IANA_stewardship This survey will be open from 13 October to 20 October 2014, and the results will be made available to the community on 24 October 2014. We have also created a public mailing list (iana-transition at arin.net) to facilitate open community discussion in the region regarding the IANA Stewardship Transition planning process. We encourage you to subscribe and participate in this dialog by visiting http://lists.arin.net/mailman/listinfo/iana-transition To learn more about this and other mailing lists hosted by ARIN, visit the Mailing List page: https://www.arin.net/participate/mailing_lists/ Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From charles at thefnf.org Tue Oct 14 22:17:20 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Tue, 14 Oct 2014 17:17:20 -0500 Subject: Scaling from home broom closet to multisite "home" data center/WAN network on a budget Message-ID: <24c1a5d19262a7dd15e35160db7f31ab@thefnf.org> Hi everybody, It's been a long time since I've kicked up a new thread here on ye ol nanog. Recently I've been putting some serious thought into home "budget" data centers. What started out as a little router/switch/virt server lab by me/myself/I in 2008, has turned into a multisite (7 points of presence spread across two states), multi rack (223U, 10 racks), multi carrier (time warner, suddenlink, att dsl, att uverse, blended bandwidth) affair today. I've realized that my friends and I may need to approach things a bit more..... professionally/seriously/circumspectly (is that a word?). We run OSPF (and soon i/eBGP including out to amprnet) between all the sites, have a multi vendor (cisco/dell/pfsense/mikrotik/linux) l3/l2 network. All the gear has been sourced from flea markets/ebay etc. Anyone else on here have a similar situation? How do you deal with it? (More details/questions after the jump) I mean my little lab is not quite as .... *ahem* involved as mr morris home data center http://smorris.uber-geek.net/lab.htm but it's also just a whee bit bigger then the typical /r/homelab posts. https://commons.thefnf.org/index.php/FNF_Lab << needs a bit more work to reflect current reality, but you can get the general idea) So.... how to home/small (multisite) business datacenter/network on budgetz? Not so much the software side of things (networking/operating system etc), but more the actual layer 1 stuff (and of course software to manage all that). Things like: Power * Any good resources for wiring optimization/layout/dos/dont's? (like say how to hook up surge protector -> ups -> pdu -> gear ?) * Network UPS tools is what we are considering "betting on" for managing our multi vendor (APC/Dell/Cyclades) PDU/UPS setup across all sites. (The joys of sourcing from flea markets). Does anything better exist? Any issues with running this across a WAN? Any tips for tying it into LDAP? (We have a large amount of lab gear that we wish to make available to the public for use by reservation, we don't want them being able to turn off our production gear) :) Temperature / Environmental monitoring * I've found the temper USB sensors to be perfect for per rack temperature statistics. I believe they will do humidity as well. Any other good environmental sensors for cheap? I know about PacketFlux which is cool for an all in one solution. (I'd love to use netbotz or something, but those are pricy). Cooling * BTU calculation resources? * Cooling sizing? * How hot can gear really run? * Is per rack cooling/airflow via floor fans necessary? For now we all just have room AC cooling the gear. So far all seems well, curious if folks have done stuff like pipe AC output directly into a cabinet etc? Noise dampening Any good room partitions or other solutions for noise cancelling? We've got combination of closed cabs and open racks, so a rack based solution won't quite cut it. Also what about insurance? Probably a thousand other questions/comments/ideas/suggestions, but I think this should kick off a great discussion! It's funny how it kind of all just combines/grows and next thing you know, you've got yourself a whole little internet as it were. :) From shortdudey123 at gmail.com Tue Oct 14 23:29:50 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 14 Oct 2014 16:29:50 -0700 Subject: SSL 3 vulnerability released Message-ID: Just incase anyone hasn't seen yet... http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html -Grant From reed at reedloden.com Tue Oct 14 23:51:35 2014 From: reed at reedloden.com (Reed Loden) Date: Tue, 14 Oct 2014 16:51:35 -0700 Subject: SSL 3 vulnerability released In-Reply-To: References: Message-ID: <20141014165135.1da58b28.reed@reedloden.com> On Tue, 14 Oct 2014 16:29:50 -0700 Grant Ridder wrote: > Just incase anyone hasn't seen yet... > http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html One thing that's always useful to follow is Mozilla's TLS on servers recommendations (https://wiki.mozilla.org/Security/Server_Side_TLS). It's kept up-to-date pretty often and includes example configs for most web servers / load balancers (including ELBs). If you're able to (depending on who your customers are and what browsers they use), I would try to use at least the 'intermediate' configuration for anything that terminates SSL/TLS. ~reed From popalz79 at gmail.com Tue Oct 14 16:32:30 2014 From: popalz79 at gmail.com (Aslam Testing) Date: Tue, 14 Oct 2014 09:32:30 -0700 Subject: Netalyzr Android: call for volunteers In-Reply-To: <39812359-ca1e-48fe-9492-92ee8622104c@email.android.com> References: <104DBF69-3D4E-45BB-802A-ECCB04C0FF3D@gatech.edu> <39812359-ca1e-48fe-9492-92ee8622104c@email.android.com> Message-ID: Is there any plan of making the netalyzer open source , and if it is already open source please provide the link so we could use it Thanks -Aslam On Sun, Oct 12, 2014 at 4:09 PM, Jay Ashworth wrote: > Is spiffy... but any chance that you could add testing for intermediate > carrier BCP 38 compliance? > > On October 5, 2014 6:43:31 PM EDT, Srikanth Sundaresan < > srikanth at gatech.edu> wrote: > >Hi all, > > > >Netalyzr is a free network measurement and debugging app developed > >by the International Computer Science Institute, Berkeley. > > > >It is designed to check for a wide range of network problems and > >neutrality > >violations, including unadvertised port filtering, DNS wildcarding, and > > > >hidden proxy servers. Our browser applet has more than a million runs. > > > >Netalyzr for Android was released in October 2013. We are happy to > >announce a new release that has new tests for better middlebox > >probing and a better UI. > > > >If you're interested, you can download and run the app from > >Google Play [1]. If you already have the app, please consider > >updating and re-running it - it would be very helpful for us to > >capture updates regarding how the mobile Internet is evolving. > > > >Oh and: please consider watching our talk at NANOG 62 on Monday [2]! > > > >Thanks, > >The Netalyzr Team. > > > >[1] > > > https://play.google.com/store/apps/details?id=edu.berkeley.icsi.netalyzr.android&hl=en > >[2] https://www.nanog.org/meetings/abstract?id=2419 > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From chad at xkl.com Wed Oct 15 00:06:04 2014 From: chad at xkl.com (Chad Lamb) Date: Tue, 14 Oct 2014 17:06:04 -0700 Subject: Multi-port RFC2544/EtherSAM loopback appliance In-Reply-To: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca> References: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca> Message-ID: <543DBA6C.1060003@xkl.com> We have been using the VeEX UX400 platform. It has a portable and rack-mount version, we have the portable so I can't comment on the rack-mount variant. We found the price/feature set to be better than several other vendors that we evaluated. We've had the equipment for several months now and found it to perform great. chad On 9/26/14, 7:51 AM, Jason Lixfeld wrote: > Group, > > I'm looking for options and opinions on a cost effective, multi-port (6'ish port SFP/SFP+) RFC2544/EtherSAM rack appliance that can act as the remote/loopback for our field installers' portable RFC2544/EtherSAM enabled Exfo test sets. > > I came across XenaNetworks XenaCompact which looks like it would fit the bill, but I'm sure there are others (save Ixia, Exfo and Fluke, which I'm pretty much excluding by default because I imagine they are likely completely out to lunch on price relative to the extremely simplified feature set we require). > > Thanks in advance. The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From jbates at paradoxnetworks.net Wed Oct 15 17:55:51 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Wed, 15 Oct 2014 12:55:51 -0500 Subject: Anyone shed light on Verizon blocking pop3 offnetwork? Message-ID: <543EB527.1000000@paradoxnetworks.net> I have a customer that left Verizon FIOS when he moved but kept his email address. About a month ago, he says his pop3 quit connecting. I've tested the ports he's using and notice they aren't responding. He's tried helpdesk and they sent him to the abuse whitelist. He tried the abuse@, which of course wouldn't be the correct location. Any recommendations? Jack From colton.conor at gmail.com Wed Oct 15 18:06:56 2014 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 15 Oct 2014 13:06:56 -0500 Subject: Keeping Track of Data Usage in GB Per Port Message-ID: I see in past news articles that cable companies are inaccurately calculating customers data usage for their online GB of usage per month. My question is how do you properly determine how much traffic in bytes a port passes per month? Is it different if we are talking about an ethernet port on a cisco switch vs a DSL port on a DSLAM for example? I would think these access switches would have some sort of stat you can count similar to a utility meter reader on a house. See what it was at last month, see what is is at this month, subtract last months from this months, and the difference is the total amount used for that month. Why are the cable companies having such a hard time? Is it hard to calculate data usage per port? Is it done with SNMP or some other method? What is the best way to monitor a 48 port switch for example, and know how much traffic they used? https://gigaom.com/2013/02/07/more-bad-news-about-broadband-caps-many-meters-are-inaccurate/ From Valdis.Kletnieks at vt.edu Wed Oct 15 18:14:31 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Oct 2014 14:14:31 -0400 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: Your message of "Wed, 15 Oct 2014 13:06:56 -0500." References: Message-ID: <2990.1413396871@turing-police.cc.vt.edu> On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > on a cisco switch vs a DSL port on a DSLAM for example? I would think these > access switches would have some sort of stat you can count similar to a > utility meter reader on a house. See what it was at last month, see what is > is at this month, subtract last months from this months, and the difference > is the total amount used for that month. Assume a 20mbit connection. How many times can this roll over a 32 bit counter in a month if it's going full blast? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From markjr at easydns.com Wed Oct 15 18:15:07 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Wed, 15 Oct 2014 14:15:07 -0400 Subject: Anyone shed light on Verizon blocking pop3 offnetwork? In-Reply-To: <543EB527.1000000@paradoxnetworks.net> References: <543EB527.1000000@paradoxnetworks.net> Message-ID: <543EB9AB.4080106@easydns.com> Good luck. Let me know if you find anybody with a clue over there. Last week we took over ZoneEdit (DNS Provider + mail forwarding) and they started blocking the new ZoneEdit mail forwarders within a couple hours of go-live - almost certainly it's some statistical based block because of the sudden influx of mail from a new IP. Impossible to get ahold of anybody, multiple delist requests go unanswered. Almost considering blocking verizon across everything we control just to get somebody's f***ing attention over there. - mark Jack Bates wrote: > I have a customer that left Verizon FIOS when he moved but kept his > email address. About a month ago, he says his pop3 quit connecting. I've > tested the ports he's using and notice they aren't responding. He's > tried helpdesk and they sent him to the abuse whitelist. He tried the > abuse@, which of course wouldn't be the correct location. Any > recommendations? > > > Jack > -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From jared at puck.nether.net Wed Oct 15 18:20:10 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 15 Oct 2014 14:20:10 -0400 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: <2990.1413396871@turing-police.cc.vt.edu> References: <2990.1413396871@turing-police.cc.vt.edu> Message-ID: > On Oct 15, 2014, at 2:14 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> on a cisco switch vs a DSL port on a DSLAM for example? I would think these >> access switches would have some sort of stat you can count similar to a >> utility meter reader on a house. See what it was at last month, see what is >> is at this month, subtract last months from this months, and the difference >> is the total amount used for that month. > > Assume a 20mbit connection. How many times can this roll over a > 32 bit counter in a month if it's going full blast? If your switch doesn’t support 64-bit counters return it. - Jared From spencerg at frii.net Wed Oct 15 18:22:02 2014 From: spencerg at frii.net (Spencer Gaw) Date: Wed, 15 Oct 2014 12:22:02 -0600 Subject: Anyone shed light on Verizon blocking pop3 offnetwork? In-Reply-To: <543EB527.1000000@paradoxnetworks.net> References: <543EB527.1000000@paradoxnetworks.net> Message-ID: <543EBB4A.1060505@frii.net> No issues here coming from Level 3, CenturyLink, Mammoth, or Comcast. Able to telnet to pop.verizon.net on 995 and smtp.verizon.net on 465. Regards, SG On 10/15/2014 11:55 AM, Jack Bates wrote: > I have a customer that left Verizon FIOS when he moved but kept his > email address. About a month ago, he says his pop3 quit connecting. > I've tested the ports he's using and notice they aren't responding. > He's tried helpdesk and they sent him to the abuse whitelist. He tried > the abuse@, which of course wouldn't be the correct location. Any > recommendations? > > > Jack From jbates at paradoxnetworks.net Wed Oct 15 18:26:44 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Wed, 15 Oct 2014 13:26:44 -0500 Subject: Anyone shed light on Verizon blocking pop3 offnetwork? In-Reply-To: <543EBB4A.1060505@frii.net> References: <543EB527.1000000@paradoxnetworks.net> <543EBB4A.1060505@frii.net> Message-ID: <543EBC64.4030303@paradoxnetworks.net> I have 5 telephone companies that cannot reach it. :( jack On 10/15/2014 1:22 PM, Spencer Gaw wrote: > No issues here coming from Level 3, CenturyLink, Mammoth, or Comcast. > Able to telnet to pop.verizon.net on 995 and smtp.verizon.net on 465. > > Regards, > > SG > > On 10/15/2014 11:55 AM, Jack Bates wrote: >> I have a customer that left Verizon FIOS when he moved but kept his >> email address. About a month ago, he says his pop3 quit connecting. >> I've tested the ports he's using and notice they aren't responding. >> He's tried helpdesk and they sent him to the abuse whitelist. He >> tried the abuse@, which of course wouldn't be the correct location. >> Any recommendations? >> >> >> Jack > From nanog at jack.fr.eu.org Wed Oct 15 18:40:35 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 15 Oct 2014 20:40:35 +0200 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: <2990.1413396871@turing-police.cc.vt.edu> References: <2990.1413396871@turing-police.cc.vt.edu> Message-ID: <543EBFA3.4080002@jack.fr.eu.org> Folks, use sflow with rrdtool! Quite awesome & handy On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> on a cisco switch vs a DSL port on a DSLAM for example? I would think these >> access switches would have some sort of stat you can count similar to a >> utility meter reader on a house. See what it was at last month, see what is >> is at this month, subtract last months from this months, and the difference >> is the total amount used for that month. > > Assume a 20mbit connection. How many times can this roll over a > 32 bit counter in a month if it's going full blast? > From colton.conor at gmail.com Wed Oct 15 19:38:09 2014 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 15 Oct 2014 14:38:09 -0500 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: <543EBFA3.4080002@jack.fr.eu.org> References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: So based on the response I have received so far it seems cable was a complicated example with service flows involved. What if we are talking about something simpler like keeping track of how much data flows in and out of a port on a switch in a given month? I know you can use SNMP, but I believe that polls in intervals and takes samples which isn't really accurate right? On Wed, Oct 15, 2014 at 1:40 PM, wrote: > Folks, use sflow with rrdtool! > > Quite awesome & handy > > On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > > > >> on a cisco switch vs a DSL port on a DSLAM for example? I would think > these > >> access switches would have some sort of stat you can count similar to a > >> utility meter reader on a house. See what it was at last month, see > what is > >> is at this month, subtract last months from this months, and the > difference > >> is the total amount used for that month. > > > > Assume a 20mbit connection. How many times can this roll over a > > 32 bit counter in a month if it's going full blast? > > > > From jof at thejof.com Wed Oct 15 20:18:35 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 15 Oct 2014 13:18:35 -0700 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: On Wed, Oct 15, 2014 at 12:38 PM, Colton Conor wrote: > So based on the response I have received so far it seems cable was a > complicated example with service flows involved. What if we are talking > about something simpler like keeping track of how much data flows in and > out of a port on a switch in a given month? I know you can use SNMP, but I > believe that polls in intervals and takes samples which isn't really > accurate right? It depends on what you're talking about. Network devices implementing the SNMP IF-MIB have counters for each interface that when polled, show the number of bytes being transmitted and received. Conventionally, network operators poll these counter values, compute the difference from the last time it was polled, and extrapolate a rate (bit volume over a time unit) from that. Often, this is done over a 5 minute interval. This introduces some averaging error. However, if an operator is just computing cumulative transfer, it's pretty easy. Just continue to sum up the counter value deltas from poll to poll. It could be easy to mess this up if the counter size is too small, or rolls more than once in-between polls. If a large telecom can't get billing correct, they shouldn't be allowed to do business. Easier solution: stop metering customers, and sink more money into expanded infrastructure. From jbates at paradoxnetworks.net Wed Oct 15 20:23:34 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Wed, 15 Oct 2014 15:23:34 -0500 Subject: UPDATE: Anyone shed light on Verizon blocking pop3 offnetwork? In-Reply-To: <543EB527.1000000@paradoxnetworks.net> References: <543EB527.1000000@paradoxnetworks.net> Message-ID: <543ED7C6.7060302@paradoxnetworks.net> Okay. This appears to be Network based filters. We cannot connect from networks in 104/8, 158/8, or 107/8. We are able to connect using the provider IP Address on the border routers. We also had an upstream test from 199/8 and they were successful. I've already sent emails to the whois contact without response. Jack Bates On 10/15/2014 12:55 PM, Jack Bates wrote: > I have a customer that left Verizon FIOS when he moved but kept his > email address. About a month ago, he says his pop3 quit connecting. > I've tested the ports he's using and notice they aren't responding. > He's tried helpdesk and they sent him to the abuse whitelist. He tried > the abuse@, which of course wouldn't be the correct location. Any > recommendations? > > > Jack From Jason_Livingood at cable.comcast.com Wed Oct 15 20:32:04 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 15 Oct 2014 20:32:04 +0000 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: Message-ID: You may want to start learning more at http://www.netforecast.com/wp-content/uploads/2014/05/NFR5116_Comcast_Meter_Accuracy_Report.pdf. This report is written by Netforecast – the same firm interviewed by GigaOm in the story link you provided. Their first audit was in 2009: http://www.netforecast.com/wp-content/uploads/2012/06/NFR5101_Comcast_Usage_Meter_Accuracy_Original.pdf Their 2nd audit was in 2010: http://www.netforecast.com/wp-content/uploads/2012/06/NFR5101_Comcast_Usage_Meter_Accuracy.pdf And here is a report on best practices for data usage in cable networks: http://www.netforecast.com/wp-content/uploads/2012/10/NFR5110_ISP_Data_Usage_Meter_Specification_Best_Practices_for_MSOs1.pdf - Jason Livingood Comcast On 10/15/14, 12:06 PM, "Colton Conor" > wrote: I see in past news articles that cable companies are inaccurately calculating customers data usage for their online GB of usage per month. My question is how do you properly determine how much traffic in bytes a port passes per month? Is it different if we are talking about an ethernet port on a cisco switch vs a DSL port on a DSLAM for example? I would think these access switches would have some sort of stat you can count similar to a utility meter reader on a house. See what it was at last month, see what is is at this month, subtract last months from this months, and the difference is the total amount used for that month. Why are the cable companies having such a hard time? Is it hard to calculate data usage per port? Is it done with SNMP or some other method? What is the best way to monitor a 48 port switch for example, and know how much traffic they used? https://gigaom.com/2013/02/07/more-bad-news-about-broadband-caps-many-meters-are-inaccurate/ From Jason_Livingood at cable.comcast.com Wed Oct 15 20:33:07 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 15 Oct 2014 20:33:07 +0000 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: There are lots of ways to do it. Cable uses IPDR, which is baked into DOCSIS standards. http://en.wikipedia.org/wiki/Internet_Protocol_Detail_Record On 10/15/14, 1:38 PM, "Colton Conor" wrote: >So based on the response I have received so far it seems cable was a >complicated example with service flows involved. What if we are talking >about something simpler like keeping track of how much data flows in and >out of a port on a switch in a given month? I know you can use SNMP, but I >believe that polls in intervals and takes samples which isn't really >accurate right? > >On Wed, Oct 15, 2014 at 1:40 PM, wrote: > >> Folks, use sflow with rrdtool! >> >> Quite awesome & handy >> >> On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: >> > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: >> > >> >> on a cisco switch vs a DSL port on a DSLAM for example? I would think >> these >> >> access switches would have some sort of stat you can count similar >>to a >> >> utility meter reader on a house. See what it was at last month, see >> what is >> >> is at this month, subtract last months from this months, and the >> difference >> >> is the total amount used for that month. >> > >> > Assume a 20mbit connection. How many times can this roll over a >> > 32 bit counter in a month if it's going full blast? >> > >> >> From joe at nethead.com Thu Oct 16 00:43:27 2014 From: joe at nethead.com (Joe Hamelin) Date: Wed, 15 Oct 2014 17:43:27 -0700 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: > > > On 10/15/14, 1:38 PM, "Colton Conor" wrote: > > >So based on the response I have received so far it seems cable was a > >complicated example with service flows involved. > Don't forget that between your port on your DSL/Cable modem and the actual port they may be monitoring there could be transitions through various protocols that can chew up bandwidth with framing bits and whatnot. See: http://www.yourdictionary.com/cell-tax as an example. This can, in worse but common cases, be as much as one fifth of the bandwidth. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From mloftis at wgops.com Thu Oct 16 01:20:18 2014 From: mloftis at wgops.com (Michael Loftis) Date: Wed, 15 Oct 2014 18:20:18 -0700 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: Message-ID: IPDR under DOCSIS and generally RADIUS or TACACS(+) for DSL. Unclear personally about fiber/FiOS deployments (never been near enough to know) Flow (sflow, nflow, ipfix, etc) generally doesn't scale and is woefully inaccurate. On Wednesday, October 15, 2014, Colton Conor wrote: > I see in past news articles that cable companies are inaccurately > calculating customers data usage for their online GB of usage per month. My > question is how do you properly determine how much traffic in bytes a port > passes per month? Is it different if we are talking about an ethernet port > on a cisco switch vs a DSL port on a DSLAM for example? I would think these > access switches would have some sort of stat you can count similar to a > utility meter reader on a house. See what it was at last month, see what is > is at this month, subtract last months from this months, and the difference > is the total amount used for that month. > > Why are the cable companies having such a hard time? Is it hard to > calculate data usage per port? Is it done with SNMP or some other method? > > What is the best way to monitor a 48 port switch for example, and know how > much traffic they used? > > > https://gigaom.com/2013/02/07/more-bad-news-about-broadband-caps-many-meters-are-inaccurate/ > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From aj at jonesy.com.au Thu Oct 16 04:01:44 2014 From: aj at jonesy.com.au (Andrew Jones) Date: Thu, 16 Oct 2014 15:01:44 +1100 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: Message-ID: <63cceec445c47bd43dcd9f02bcc41288@jonesy.com.au> This all becomes even more complicated when some traffic isn't counted (Eg. "free facebook") on a given service which generally then necessitates the need for some level of flow-based accounting, even if it's just collecting flows for the free traffic to subtract from the port counters. I can see how it could get messy. On 16.10.2014 12:20, Michael Loftis wrote: > IPDR under DOCSIS and generally RADIUS or TACACS(+) for DSL. Unclear > personally about fiber/FiOS deployments (never been near enough to > know) > > Flow (sflow, nflow, ipfix, etc) generally doesn't scale and is > woefully > inaccurate. > > On Wednesday, October 15, 2014, Colton Conor > wrote: > >> I see in past news articles that cable companies are inaccurately >> calculating customers data usage for their online GB of usage per >> month. My >> question is how do you properly determine how much traffic in bytes >> a port >> passes per month? Is it different if we are talking about an >> ethernet port >> on a cisco switch vs a DSL port on a DSLAM for example? I would >> think these >> access switches would have some sort of stat you can count similar >> to a >> utility meter reader on a house. See what it was at last month, see >> what is >> is at this month, subtract last months from this months, and the >> difference >> is the total amount used for that month. >> >> Why are the cable companies having such a hard time? Is it hard to >> calculate data usage per port? Is it done with SNMP or some other >> method? >> >> What is the best way to monitor a 48 port switch for example, and >> know how >> much traffic they used? >> >> >> >> https://gigaom.com/2013/02/07/more-bad-news-about-broadband-caps-many-meters-are-inaccurate/ >> From rjoffe at centergate.com Thu Oct 16 04:42:20 2014 From: rjoffe at centergate.com (Rodney Joffe) Date: Thu, 16 Oct 2014 00:42:20 -0400 Subject: Sigh. 16 years ago today. Message-ID: <5D41F2A6-C5E4-4CE1-B196-997D2708BDBB@centergate.com> https://www.ietf.org/rfc/rfc2468.txt From randy at psg.com Thu Oct 16 06:07:35 2014 From: randy at psg.com (Randy Bush) Date: Wed, 15 Oct 2014 23:07:35 -0700 Subject: Sigh. 16 years ago today. In-Reply-To: <5D41F2A6-C5E4-4CE1-B196-997D2708BDBB@centergate.com> References: <5D41F2A6-C5E4-4CE1-B196-997D2708BDBB@centergate.com> Message-ID: why i dread october: jon, abha, itojun From larrysheldon at cox.net Thu Oct 16 06:20:16 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 16 Oct 2014 01:20:16 -0500 Subject: Sigh. 16 years ago today. In-Reply-To: <3gj81p00k1cZc5601gjACa> References: <3gj81p00k1cZc5601gjACa> Message-ID: <543F63A0.3070007@cox.net> On 10/15/2014 23:42, Rodney Joffe wrote: > https://www.ietf.org/rfc/rfc2468.txt > I posted this to Facebook a while ago: From NANOG Subject: Sigh. 16 years ago today. https://www.ietf.org/rfc/rfc2468.txt [Ed. note: The man being remembered was important, and in ways, still is. But I mention it also because it points out that whereas we bang our heads against soul-less monoliths, it seems, in the early days it was a really small, close-knit group that brought this Internet thing out of the labs and stood it up and made it play in remarkably productive ways.] -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From mitch at nac.net Thu Oct 16 13:16:59 2014 From: mitch at nac.net (Mitch Arthur) Date: Thu, 16 Oct 2014 09:16:59 -0400 Subject: Sigh. 16 years ago today. In-Reply-To: <5D41F2A6-C5E4-4CE1-B196-997D2708BDBB@centergate.com> References: <5D41F2A6-C5E4-4CE1-B196-997D2708BDBB@centergate.com> Message-ID: <007801cfe943$77a8de30$66fa9a90$@net> Rodney thanks for posting; I really enjoyed reading it. These treasures keep alive the historical significance of those who realized this technology that most today take for granted. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rodney Joffe Sent: Thursday, October 16, 2014 12:42 AM To: NANOG Subject: Sigh. 16 years ago today. https://www.ietf.org/rfc/rfc2468.txt From drew.linsalata at gmail.com Thu Oct 16 17:03:14 2014 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 16 Oct 2014 13:03:14 -0400 Subject: VZW IPv6 routing issues? Message-ID: Shot in the dark here, but we're starting to see complaints from a few VZW customers that can no longer access mail services we're providing on the usual IMAP and POP ports (secure or otherwise). It only seems to be happening for users that are getting IPv6 addresses for cellular data. Web traffic isn't an issue, just mail. Has anyone else seen this? From jra at baylink.com Thu Oct 16 17:30:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 16 Oct 2014 13:30:04 -0400 (EDT) Subject: BCP38 wiki reminder Message-ID: <16845733.5837.1413480604642.JavaMail.root@benjamin.baylink.com> Thanks to several folks who've recently asked me to create accounts for them on the BCP38.info wiki. (We had to leave it on manual because we couldn't come up with a reasonable way to despam it, and were stuck on an older release; I think that might have changed now...) We welcome all contributions to the site, in the name of reducing untraceable DOS attacks on the greater Internet. I've filled in the articles for which I have first hand knowledge, but we still need contributions from people with experience running larger more complex edge networks, and also parts of the core. Got some free time this weekend? Here's your chance to be Smart and Helpful! Cheers, -- jr 'or whacky; whichever you prefer' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jneiberger at gmail.com Thu Oct 16 18:03:15 2014 From: jneiberger at gmail.com (John Neiberger) Date: Thu, 16 Oct 2014 12:03:15 -0600 Subject: Need a contact at Earthlink Business (AS 6983, formerly Deltacom) for routing issue Message-ID: ​If someone from AS 6983 is on the list, please reach out to me off-list. AS 6983 is currently advertising a /24 from our space. Thanks, John​ From owen at delong.com Thu Oct 16 18:18:11 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Oct 2014 11:18:11 -0700 Subject: Sigh. 16 years ago today. In-Reply-To: <543F63A0.3070007@cox.net> References: <3gj81p00k1cZc5601gjACa> <543F63A0.3070007@cox.net> Message-ID: <4C354EE4-363F-4015-9562-AA01FBF32BFC@delong.com> On Oct 15, 2014, at 23:20 , Larry Sheldon wrote: > On 10/15/2014 23:42, Rodney Joffe wrote: >> https://www.ietf.org/rfc/rfc2468.txt >> > > I posted this to Facebook a while ago: > > From NANOG > > Subject: Sigh. 16 years ago today. > > https://www.ietf.org/rfc/rfc2468.txt > > [Ed. note: The man being remembered was important, and in ways, still is. But I mention it also because it points out that whereas we bang our heads against soul-less monoliths, it seems, in the early days it was a really small, close-knit group that brought this Internet thing out of the labs and stood it up and made it play in remarkably productive ways.] In many ways, today, it is a larger and more diverse group, but the bottom line is that behind all those peering relationships, NANOG conferences, ARIN meetings, etc. are a dedicated group of engineers just trying to keep it all functional. Owen > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes From Courtney_Smith at Cable.Comcast.com Thu Oct 16 20:39:14 2014 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 16 Oct 2014 20:39:14 +0000 Subject: Anyone from AS6983 here? Message-ID: AS6983 is announcing a /24 out of space allocated to AS7922. Having trouble getting sorted out with 6983’s NOC. Thanks. route-server.phx1>show ip bgp 198.0.0.0/16 long BGP table version is 1479726026, local router ID is 67.17.81.28 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i198.0.0.0 67.16.148.37 36 300 0 6983 ? * i 67.16.148.37 36 300 0 6983 ? * i198.0.0.0/16 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i *>i 67.16.148.37 50 199 0 7922 i * i 67.16.148.37 50 199 0 7922 i route-server.phx1> http://whois.arin.net/rest/net/NET-198-0-0-0-1 P.S. We have asked Level3 to block the announcement. From Courtney_Smith at Cable.Comcast.com Thu Oct 16 21:14:09 2014 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 16 Oct 2014 21:14:09 +0000 Subject: Anyone from AS6983 here? In-Reply-To: References: Message-ID: A few folks replied off=list. This has been resolved. Thanks. On 10/16/14, 4:39 PM, "Smith, Courtney" wrote: >AS6983 is announcing a /24 out of space allocated to AS7922. Having >trouble getting sorted out with 6983¹s NOC. Thanks. > >route-server.phx1>show ip bgp 198.0.0.0/16 long >BGP table version is 1479726026, local router ID is 67.17.81.28 >Status codes: s suppressed, d damped, h history, * valid, > best, i - >internal, > r RIB-failure, S Stale, m multipath, b backup-path, x >best-external >Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path >*>i198.0.0.0 67.16.148.37 36 300 0 6983 ? >* i 67.16.148.37 36 300 0 6983 ? >* i198.0.0.0/16 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >*>i 67.16.148.37 50 199 0 7922 i >* i 67.16.148.37 50 199 0 7922 i >route-server.phx1> > >http://whois.arin.net/rest/net/NET-198-0-0-0-1 > > > >P.S. We have asked Level3 to block the announcement. > From joew13 at outlook.com Wed Oct 15 15:07:27 2014 From: joew13 at outlook.com (Joe White) Date: Wed, 15 Oct 2014 11:07:27 -0400 Subject: Ashburn VA Colo Message-ID: Good morning! I am interested in obtaining a small initial footprint for colo within the Ashburn VA area. Can anyone make a recommendation to include a cabinet or two? Alternatively, I am familiar with Equinix and would consider space from any existing customers in the Equinix facility with space to sell! If you want to contact me off-list for details, I can provide the details. Thanks! From deanperrine at gmail.com Fri Oct 17 01:25:33 2014 From: deanperrine at gmail.com (Dean Perrine) Date: Thu, 16 Oct 2014 18:25:33 -0700 Subject: Major Level3 Issues Message-ID: Just had major outages on our Level3 connections across the country. (LA, TX, ORD) Anyone have any news / updates which can be shared? Looks like AT&T and XO had loss of connectivity to Level3? Thank you! Dean From jason at unlimitednet.us Fri Oct 17 01:32:01 2014 From: jason at unlimitednet.us (Jason Canady) Date: Thu, 16 Oct 2014 21:32:01 -0400 Subject: Major Level3 Issues In-Reply-To: References: Message-ID: <5E31C989-D5C4-4651-BBA0-449EB1BA6DB5@unlimitednet.us> Dean, Best I have is from their portal: The IP NOC reports that a module failed on a device in Chicago, IL causing additional impact to IP services across Multiple Markets. The IP NOC has confirmed that the module initially failed and recovered prior to manual intervention. A short time later, the module failed again, restored of its own accord and continued to bounce thereafter. Services have since been restored and stable as of approximately 23:54 GMT. The equipment vendor is being engaged to assist in isolation efforts to determine a root cause and the IP NOC is continuing to monitor at this time. We rerouted away majority traffic from Level 3 and will leave it till late tonight or early morning. We experienced two major blips tonight. Jason On Oct 16, 2014, at 21:25, Dean Perrine wrote: > Just had major outages on our Level3 connections across the country. (LA, > TX, ORD) > > Anyone have any news / updates which can be shared? > > Looks like AT&T and XO had loss of connectivity to Level3? > > Thank you! > Dean From jbfixurpc at gmail.com Fri Oct 17 04:37:40 2014 From: jbfixurpc at gmail.com (Joe) Date: Thu, 16 Oct 2014 23:37:40 -0500 Subject: Anyone seeing issues with TWC inWI at the moment? Message-ID: Might just be me but seeiing extrememly long delays to their web servers [root at storage ~]# curl http://www.timewarnercable.com/>here % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 331 100 331 0 0 5 0 0:01:06 0:00:59 0:00:07 67 [root at storage ~]# traceroute to www.timewarnercable.com (71.74.42.231), 30 hops max, 60 byte packets 5 tge1-1-0-8.milzwift01r.midwest.rr.com (65.29.44.158) 33.204 ms 33.426 ms 33.509 ms 6 bu-ether18.cr0.chi30.tbone.rr.com (66.109.6.206) 36.901 ms 17.829 ms 23.836 ms 7 ae-0-0.cr0.chi10.tbone.rr.com (66.109.6.20) 37.020 ms 37.239 ms 40.098 ms 8 ge-5-0-0.ar1.cdp01.tbone.rr.com (66.109.10.221) 64.300 ms 64.687 ms 64.588 ms 9 66.109.10.73 (66.109.10.73) 44.083 ms 45.343 ms 45.534 ms 10 75.180.131.165 (75.180.131.165) 48.200 ms 48.925 ms 50.939 ms 11 75.180.131.229 (75.180.131.229) 64.520 ms 65.393 ms 65.155 ms 12 www.timewarnercable.com (71.74.42.231) 41.589 ms 35.222 ms 34.410 ms [root at storage ~]# wget http://www.timewarnercable.com/>here --2014-10-16 23:34:28-- http://www.timewarnercable.com/ Resolving www.timewarnercable.com... 71.74.42.231, 2001:1998:840:b001::7 Connecting to www.timewarnercable.com|71.74.42.231|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.timewarnercable.com/en/residential.html [following] --2014-10-16 23:35:07-- http://www.timewarnercable.com/en/residential.html Reusing existing connection to www.timewarnercable.com:80. HTTP request sent, awaiting response... 200 OK Length: 142374 (139K) [text/html] Saving to: “residential.html.2” 100%[======================================>] 142,374 710K/s in 0.2s 2014-10-16 23:35:07 (710 KB/s) - “residential.html.2” saved [142374/142374] Probably just me or poor residential folks , but just wondering. Sorry to bother! Thanks -Joe From daniel.crompton at gmail.com Fri Oct 17 09:49:59 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Fri, 17 Oct 2014 11:49:59 +0200 Subject: Sigh. 16 years ago today. In-Reply-To: <4C354EE4-363F-4015-9562-AA01FBF32BFC@delong.com> References: <543F63A0.3070007@cox.net> <4C354EE4-363F-4015-9562-AA01FBF32BFC@delong.com> Message-ID: At the time he died I was just being introduced to Internet, and first read his name when reading rfc 821. I had never really heard of Jon Postel's legacy until a remembrance on this list some years back which is when I added a reminder to my calendar. Every year it reminds me that "*if I have seen further it is by standing on the shoulders of giants.*" D. Oplerno is built upon empowering faculty and students -- Daniël W. Crompton http://specialbrands.net/ On 16 October 2014 20:18, Owen DeLong wrote: > > On Oct 15, 2014, at 23:20 , Larry Sheldon wrote: > > > On 10/15/2014 23:42, Rodney Joffe wrote: > >> https://www.ietf.org/rfc/rfc2468.txt > >> > > > > I posted this to Facebook a while ago: > > > > From NANOG > > > > Subject: Sigh. 16 years ago today. > > > > https://www.ietf.org/rfc/rfc2468.txt > > > > [Ed. note: The man being remembered was important, and in ways, still > is. But I mention it also because it points out that whereas we bang our > heads against soul-less monoliths, it seems, in the early days it was a > really small, close-knit group that brought this Internet thing out of the > labs and stood it up and made it play in remarkably productive ways.] > > In many ways, today, it is a larger and more diverse group, but the bottom > line is that behind all those peering relationships, NANOG conferences, > ARIN meetings, etc. are a dedicated group of engineers just trying to keep > it all functional. > > Owen > > > > > -- > > The unique Characteristics of System Administrators: > > > > The fact that they are infallible; and, > > > > The fact that they learn from their mistakes. > > > > > > Quis custodiet ipsos custodes > > From tony at lavanauts.org Fri Oct 17 17:04:38 2014 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 17 Oct 2014 07:04:38 -1000 (HST) Subject: fema.net dnssec issues Message-ID: Anybody have a good DNS tech contact at FEMA? I tried to report a dnssec problem to them but apparently the contact listed in whois is out of the office. In the meantime we have a near hurricane-strength storm approaching. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From cscora at apnic.net Fri Oct 17 18:11:32 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Oct 2014 04:11:32 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201410171811.s9HIBWDX019912@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, TRNOG, 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 Oct, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 514323 Prefixes after maximum aggregation: 199484 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 253096 Total ASes present in the Internet Routing Table: 48320 Prefixes per ASN: 10.64 Origin-only ASes present in the Internet Routing Table: 36273 Origin ASes announcing only one prefix: 16350 Transit ASes present in the Internet Routing Table: 6150 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 118 Max AS path prepend of ASN ( 55644) 111 Prefixes from unregistered ASNs in the Routing Table: 1847 Unregistered ASNs in the Routing Table: 448 Number of 32-bit ASNs allocated by the RIRs: 7652 Number of 32-bit ASNs visible in the Routing Table: 5897 Prefixes from 32-bit ASNs in the Routing Table: 20879 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 344 Number of addresses announced to Internet: 2711955588 Equivalent to 161 /8s, 165 /16s and 40 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176391 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 125598 Total APNIC prefixes after maximum aggregation: 36783 APNIC Deaggregation factor: 3.41 Prefixes being announced from the APNIC address blocks: 129541 Unique aggregates announced from the APNIC address blocks: 53632 APNIC Region origin ASes present in the Internet Routing Table: 4976 APNIC Prefixes per ASN: 26.03 APNIC Region origin ASes announcing only one prefix: 1187 APNIC Region transit ASes present in the Internet Routing Table: 854 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 118 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1133 Number of APNIC addresses announced to Internet: 735980480 Equivalent to 43 /8s, 222 /16s and 43 /24s Percentage of available APNIC address space announced: 86.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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, 150/8, 153/8, 163/8, 171/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: 171583 Total ARIN prefixes after maximum aggregation: 85311 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173348 Unique aggregates announced from the ARIN address blocks: 81069 ARIN Region origin ASes present in the Internet Routing Table: 16381 ARIN Prefixes per ASN: 10.58 ARIN Region origin ASes announcing only one prefix: 6108 ARIN Region transit ASes present in the Internet Routing Table: 1693 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 225 Number of ARIN addresses announced to Internet: 1052731072 Equivalent to 62 /8s, 191 /16s and 102 /24s Percentage of available ARIN address space announced: 55.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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125359 Total RIPE prefixes after maximum aggregation: 63697 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 130763 Unique aggregates announced from the RIPE address blocks: 82810 RIPE Region origin ASes present in the Internet Routing Table: 17786 RIPE Prefixes per ASN: 7.35 RIPE Region origin ASes announcing only one prefix: 8204 RIPE Region transit ASes present in the Internet Routing Table: 2907 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3128 Number of RIPE addresses announced to Internet: 692188036 Equivalent to 41 /8s, 65 /16s and 243 /24s Percentage of available RIPE address space announced: 100.6 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58702 Total LACNIC prefixes after maximum aggregation: 10791 LACNIC Deaggregation factor: 5.44 Prefixes being announced from the LACNIC address blocks: 67386 Unique aggregates announced from the LACNIC address blocks: 30524 LACNIC Region origin ASes present in the Internet Routing Table: 2344 LACNIC Prefixes per ASN: 28.75 LACNIC Region origin ASes announcing only one prefix: 638 LACNIC Region transit ASes present in the Internet Routing Table: 463 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1356 Number of LACNIC addresses announced to Internet: 171237504 Equivalent to 10 /8s, 52 /16s and 224 /24s Percentage of available LACNIC address space announced: 102.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12101 Total AfriNIC prefixes after maximum aggregation: 2854 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 12941 Unique aggregates announced from the AfriNIC address blocks: 4757 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 17.61 AfriNIC Region origin ASes announcing only one prefix: 213 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 55 Number of AfriNIC addresses announced to Internet: 59521792 Equivalent to 3 /8s, 140 /16s and 59 /24s Percentage of available AfriNIC address space announced: 59.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2946 11584 926 Korea Telecom 17974 2827 903 77 PT Telekomunikasi Indonesia 7545 2398 336 124 TPG Telecom Limited 4755 1917 412 189 TATA Communications formerly 9829 1652 1306 39 National Internet Backbone 4808 1407 2204 419 CNCGROUP IP network China169 9808 1386 6639 15 Guangdong Mobile Communicatio 9498 1307 333 91 BHARTI Airtel Ltd. 9583 1306 104 529 Sify Limited 7552 1198 1098 14 Viettel Corporation 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 22773 2903 2941 144 Cox Communications Inc. 6389 2896 3688 51 BellSouth.net Inc. 18566 2046 379 182 MegaPath Corporation 7029 1908 1958 316 Windstream Communications Inc 20115 1806 1788 480 Charter Communications 4323 1636 1052 410 tw telecom holdings, inc. 6983 1527 867 252 ITC^Deltacom 30036 1481 308 618 Mediacom Communications Corp 701 1430 11266 714 MCI Communications Services, 22561 1305 408 237 CenturyTel Internet Holdings, 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 1826 297 349 TELLCOM ILETISIM HIZMETLERI A 20940 1500 583 1105 Akamai International B.V. 8402 1421 544 15 OJSC "Vimpelcom" 31148 1044 45 21 Freenet Ltd. 13188 1037 100 29 TOV "Bank-Inform" 8551 965 372 41 Bezeq International-Ltd 6849 835 356 26 JSC "Ukrtelecom" 6830 781 2338 434 Liberty Global Operations B.V 12479 750 784 96 France Telecom Espana SA 9198 667 346 29 JSC Kazakhtelecom 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 2994 485 254 Telmex Colombia S.A. 28573 2899 2315 110 NET Servi�os de Comunica��o S 6147 1794 374 30 Telefonica del Peru S.A.A. 7303 1756 1162 239 Telecom Argentina S.A. 8151 1476 3008 434 Uninet S.A. de C.V. 6503 1109 434 61 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 27947 911 130 51 Telconet S.A 3816 888 383 154 COLOMBIA TELECOMUNICACIONES S 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 1377 958 13 TE-AS 24863 949 280 26 Link Egypt (Link.NET) 6713 678 760 38 Office National des Postes et 36992 351 824 28 ETISALAT MISR 24835 307 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 230 19 6 Data Telecom Service 15706 186 17 6 Sudatel (Sudan Telecom Co. Lt 37457 175 160 4 Telkom SA Ltd. 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 10620 2994 485 254 Telmex Colombia S.A. 4766 2946 11584 926 Korea Telecom 22773 2903 2941 144 Cox Communications Inc. 28573 2899 2315 110 NET Servi�os de Comunica��o S 6389 2896 3688 51 BellSouth.net Inc. 17974 2827 903 77 PT Telekomunikasi Indonesia 7545 2398 336 124 TPG Telecom Limited 18566 2046 379 182 MegaPath Corporation 4755 1917 412 189 TATA Communications formerly 7029 1908 1958 316 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2896 2845 BellSouth.net Inc. 28573 2899 2789 NET Servi�os de Comunica��o S 22773 2903 2759 Cox Communications Inc. 17974 2827 2750 PT Telekomunikasi Indonesia 7545 2398 2274 TPG Telecom Limited 4766 2946 2020 Korea Telecom 18566 2046 1864 MegaPath Corporation 6147 1794 1764 Telefonica del Peru S.A.A. 4755 1917 1728 TATA Communications formerly 9829 1652 1613 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:12 /10:31 /11:90 /12:262 /13:502 /14:1005 /15:1712 /16:13039 /17:7121 /18:11854 /19:24635 /20:35174 /21:37275 /22:54800 /23:48069 /24:275809 /25:1093 /26:1062 /27:705 /28:14 /29:19 /30:10 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2134 2903 Cox Communications Inc. 18566 2001 2046 MegaPath Corporation 6389 1676 2896 BellSouth.net Inc. 6147 1358 1794 Telefonica del Peru S.A.A. 30036 1328 1481 Mediacom Communications Corp 6983 1217 1527 ITC^Deltacom 34984 1146 1826 TELLCOM ILETISIM HIZMETLERI A 7029 1144 1908 Windstream Communications Inc 11492 1124 1175 CABLE ONE, INC. 8402 1089 1421 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1352 2:678 3:3 4:17 5:1177 6:21 8:759 12:1850 13:4 14:1149 15:17 16:2 17:42 18:21 20:51 23:947 24:1769 27:1820 31:1322 32:40 33:2 34:5 36:160 37:1804 38:1005 39:20 40:227 41:2988 42:254 43:524 44:18 45:80 46:2071 47:27 49:734 50:799 52:12 54:51 55:3 56:10 57:32 58:1138 59:645 60:435 61:1729 62:1264 63:1829 64:4390 65:2274 66:4208 67:2036 68:1083 69:3262 70:873 71:477 72:1983 74:2612 75:375 76:412 77:1608 78:1017 79:765 80:1329 81:1261 82:792 83:657 84:727 85:1353 86:438 87:1152 88:497 89:1806 90:138 91:5794 92:775 93:1671 94:2033 95:1290 96:430 97:340 98:1100 99:48 100:65 101:731 103:5877 104:472 105:150 106:187 107:648 108:580 109:2000 110:1044 111:1381 112:720 113:901 114:806 115:1169 116:1145 117:1024 118:1537 119:1368 120:440 121:963 122:2200 123:1661 124:1446 125:1491 128:631 129:356 130:372 131:921 132:431 133:165 134:323 135:80 136:322 137:316 138:379 139:199 140:222 141:408 142:599 143:439 144:512 145:111 146:677 147:559 148:998 149:389 150:495 151:590 152:477 153:240 154:401 155:568 156:375 157:331 158:279 159:947 160:327 161:604 162:1805 163:403 164:646 165:669 166:365 167:680 168:1126 169:123 170:1414 171:188 172:60 173:1635 174:710 175:607 176:1521 177:3618 178:2096 179:798 180:1762 181:1766 182:1664 183:572 184:706 185:2203 186:2995 187:1647 188:2008 189:1486 190:7908 191:777 192:7704 193:5553 194:4061 195:3611 196:1635 197:758 198:5278 199:5466 200:6472 201:2901 202:9138 203:9077 204:4700 205:2655 206:3089 207:2968 208:3922 209:3762 210:3298 211:1827 212:2377 213:2168 214:861 215:85 216:5606 217:1713 218:614 219:391 220:1374 221:744 222:481 223:600 End of report From rs at seastrom.com Fri Oct 17 21:06:41 2014 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 17 Oct 2014 17:06:41 -0400 Subject: fema.net dnssec issues In-Reply-To: (Antonio Querubin's message of "Fri, 17 Oct 2014 07:04:38 -1000 (HST)") References: Message-ID: <86lhoe1k4e.fsf@valhalla.seastrom.com> Antonio Querubin writes: > Anybody have a good DNS tech contact at FEMA? I tried to report a > dnssec problem to them but apparently the contact listed in whois is > out of the office. In the meantime we have a near hurricane-strength > storm approaching. fema.net looks like it belongs to who you'd expect, and indeed the dnssec is broken, but their web site seems to be broken when you try to visit it from a non-validating location too. fema.gov appears to be working properly. it would not have occurred to me to use fema.net to contact the fema.gov people and it comes to me as a complete surprise that they even own fema.net. are they pushing fema.net in their advertising or somesuch? best of luck in the storm; stay dry. -r From cidr-report at potaroo.net Fri Oct 17 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Oct 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201410172200.s9HM00Rr018027@wattle.apnic.net> This report has been generated at Fri Oct 17 21:14:14 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-10-14 519407 288333 11-10-14 519795 288353 12-10-14 519143 288362 13-10-14 519130 288296 14-10-14 519005 288468 15-10-14 519878 287489 16-10-14 519836 287774 17-10-14 520223 287683 AS Summary 48566 Number of ASes in routing system 19571 Number of ASes announcing only one prefix 2994 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 119981312 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 17Oct14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 519775 287792 231983 44.6% All ASes AS6389 2895 102 2793 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS28573 2878 120 2758 95.8% NET Servi�os de Comunica��o S.A.,BR AS22773 2906 164 2742 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2827 95 2732 96.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2947 1208 1739 59.0% KIXS-AS-KR Korea Telecom,KR AS6147 1788 166 1622 90.7% Telefonica del Peru S.A.A.,PE AS7303 1761 289 1472 83.6% Telecom Argentina S.A.,AR AS8402 1404 25 1379 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS9808 1386 50 1336 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4755 1916 605 1311 68.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1807 555 1252 69.3% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2414 1175 1239 51.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1646 413 1233 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1309 108 1201 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS10620 2994 1807 1187 39.6% Telmex Colombia S.A.,CO AS18566 2045 867 1178 57.6% MEGAPATH5-US - MegaPath Corporation,US AS7552 1224 59 1165 95.2% VIETEL-AS-AP Viettel Corporation,VN AS6983 1528 379 1149 75.2% ITCDELTA - Earthlink, Inc.,US AS7029 2058 1062 996 48.4% WINDSTREAM - Windstream Communications Inc,US AS22561 1304 351 953 73.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS34984 1825 923 902 49.4% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS18881 887 26 861 97.1% Global Village Telecom,BR AS4788 1076 242 834 77.5% TMNET-AS-AP TM Net, Internet Service Provider,MY AS38285 954 123 831 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1176 355 821 69.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1044 258 786 75.3% FREENET-AS Freenet Ltd.,UA AS26615 914 131 783 85.7% Tim Celular S.A.,BR AS8151 1482 710 772 52.1% Uninet S.A. de C.V.,MX AS4780 1046 283 763 72.9% SEEDNET Digital United Inc.,TW Total 52440 12734 39706 75.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.220.173.0/24 AS30058 FDCSERVERS - FDCservers.net,US 91.228.160.0/24 AS19979 DEPO40-AS Trusov Ilya Igorevych,RU 93.157.184.0/22 AS12714 TI-AS Net By Net Holding LLC,RU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 104.219.40.0/22 AS8560 ONEANDONE-AS 1&1 Internet AG,DE 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.7.160.0/21 AS13703 BROADRIVER-13703 - BroadRiver Communication Corp.,US 199.7.167.0/24 AS22626 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.116.212.0/22 AS53704 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.193.192.0/19 AS22938 -Reserved AS-,ZZ 206.193.205.0/24 AS11915 US-TELEPACIFIC - TelePacific Communications,US 206.193.208.0/22 AS11915 US-TELEPACIFIC - TelePacific Communications,US 206.193.212.0/24 AS11915 US-TELEPACIFIC - TelePacific Communications,US 206.193.213.0/24 AS11915 US-TELEPACIFIC - TelePacific Communications,US 206.193.214.0/23 AS11915 US-TELEPACIFIC - TelePacific Communications,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 cidr-report at potaroo.net Fri Oct 17 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Oct 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201410172200.s9HM01Wv018045@wattle.apnic.net> BGP Update Report Interval: 09-Oct-14 -to- 16-Oct-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7552 385994 7.7% 321.4 -- VIETEL-AS-AP Viettel Corporation,VN 2 - AS23752 194595 3.9% 1785.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 181763 3.6% 163.9 -- BSNL-NIB National Internet Backbone,IN 4 - AS33748 124760 2.5% 904.1 -- DSCI - DSCI Corporation,US 5 - AS38197 107698 2.1% 122.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 6 - AS3816 80515 1.6% 126.2 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 7 - AS38623 43510 0.9% 329.6 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 8 - AS13682 38760 0.8% 4306.7 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 9 - AS31727 38024 0.8% 1728.4 -- NODE4-AS Node4 Limited,GB 10 - AS23520 32089 0.6% 179.3 -- COLUMBUS-NETWORKS - Columbus Networks USA, Inc.,US 11 - AS34984 30205 0.6% 32.3 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 12 - AS11830 28862 0.6% 60.1 -- Instituto Costarricense de Electricidad y Telecom.,CR 13 - AS8151 27870 0.6% 19.8 -- Uninet S.A. de C.V.,MX 14 - AS28573 26502 0.5% 16.7 -- NET Servi�os de Comunica��o S.A.,BR 15 - AS12066 24011 0.5% 212.5 -- TRICOM,DO 16 - AS30036 22320 0.4% 22.0 -- MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 17 - AS23342 22150 0.4% 22150.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 18 - AS13188 21342 0.4% 22.7 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 19 - AS647 20732 0.4% 162.0 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 20 - AS10620 20481 0.4% 32.8 -- Telmex Colombia S.A.,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23342 22150 0.4% 22150.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 2 - AS18135 10203 0.2% 10203.0 -- BTV BTV Cable television,JP 3 - AS32336 7268 0.1% 7268.0 -- IPASS-2 - iPass Incorporated,US 4 - AS42029 6015 0.1% 6015.0 -- ILLION Illion HB,SE 5 - AS48315 4755 0.1% 4755.0 -- ALPHANETWORKS-AS Alpha Networks S.P.R.L. 's AS number,BE 6 - AS47680 4670 0.1% 4670.0 -- NHCS EOBO Limited,IE 7 - AS13682 38760 0.8% 4306.7 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 8 - AS2 4205 0.1% 661.0 -- UDEL-DCN - University of Delaware,US 9 - AS52355 7946 0.2% 3973.0 -- Jalasoft Corp.,BO 10 - AS62174 3924 0.1% 3924.0 -- INTERPAN-AS INTERPAN LTD.,BG 11 - AS2 3085 0.1% 1435.0 -- UDEL-DCN - University of Delaware,US 12 - AS47887 7835 0.2% 2611.7 -- NEU-AS AL-HADATHEH LIL-ITISALAT WA AL-TECHNOLOGIA CO.,JO 13 - AS8738 2319 0.1% 2319.0 -- VISA-ISRAEL-AS Israel Credit Cards Ltd,IL 14 - AS35093 4150 0.1% 2075.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 15 - AS55917 2056 0.0% 2056.0 -- IYOGI-IN Building No:6 Tower C FF,IN 16 - AS8621 3836 0.1% 1918.0 -- BBUK-LTD Backbone (UK) Limited,GB 17 - AS39620 1894 0.0% 1894.0 -- S2S-UK s2s Uk Ltd,GB 18 - AS58117 5598 0.1% 1866.0 -- SWORDFISH Swordfish Hosting Limited,GB 19 - AS34934 1866 0.0% 1866.0 -- UKFAST UKfastnet Ltd,GB 20 - AS6629 11160 0.2% 1860.0 -- NOAA-AS - NOAA,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 97964 1.9% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 95218 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 64.29.130.0/24 22150 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 4 - 192.115.44.0/22 19564 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 5 - 200.34.149.0/24 11558 0.2% AS8151 -- Uninet S.A. de C.V.,MX 6 - 192.58.232.0/24 11133 0.2% AS6629 -- NOAA-AS - NOAA,US 7 - 63.251.136.0/23 10858 0.2% AS33748 -- DSCI - DSCI Corporation,US 8 - 63.251.136.0/24 10828 0.2% AS33748 -- DSCI - DSCI Corporation,US 9 - 63.251.139.0/24 10815 0.2% AS33748 -- DSCI - DSCI Corporation,US 10 - 63.251.137.0/24 10802 0.2% AS33748 -- DSCI - DSCI Corporation,US 11 - 63.251.138.0/24 10774 0.2% AS33748 -- DSCI - DSCI Corporation,US 12 - 42.83.48.0/20 10203 0.2% AS18135 -- BTV BTV Cable television,JP 13 - 200.119.160.0/19 8529 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 14 - 190.143.240.0/20 8510 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 15 - 188.123.160.0/19 7829 0.1% AS47887 -- NEU-AS AL-HADATHEH LIL-ITISALAT WA AL-TECHNOLOGIA CO.,JO 16 - 216.231.194.0/24 7268 0.1% AS32336 -- IPASS-2 - iPass Incorporated,US 17 - 64.94.246.0/24 6998 0.1% AS33748 -- DSCI - DSCI Corporation,US 18 - 64.94.244.0/23 6956 0.1% AS33748 -- DSCI - DSCI Corporation,US 19 - 64.95.78.0/24 6882 0.1% AS33748 -- DSCI - DSCI Corporation,US 20 - 41.221.20.0/24 6542 0.1% AS36947 -- ALGTEL-AS,DZ 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 surfer at mauigateway.com Fri Oct 17 22:12:48 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 17 Oct 2014 15:12:48 -0700 Subject: hawaii hurricane [was] Re: fema.net dnssec issues Message-ID: <20141017151248.11E93CC9@m0005296.ppops.net> --- rs at seastrom.com wrote: From: Rob Seastrom best of luck in the storm; stay dry. ---------------------------------------- For anyone who has stuff in Hawaii, it's hitting the Big Island already. Now we'll see which DR plans work and which don't. ;-) http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&period=720&incr=30&rr=900&banner=uhmet&satplat=goeswest&overlay=off http://www.prh.noaa.gov/cphc http://www.prh.noaa.gov/cphc/tc_graphics/2014/sat/probCP022014_141017_2030_sata.gif scott From randy at psg.com Sat Oct 18 15:11:43 2014 From: randy at psg.com (Randy Bush) Date: Sat, 18 Oct 2014 08:11:43 -0700 Subject: hawaii hurricane [was] Re: fema.net dnssec issues In-Reply-To: <20141017151248.11E93CC9@m0005296.ppops.net> References: <20141017151248.11E93CC9@m0005296.ppops.net> Message-ID: > http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&period=720&incr=30&rr=900&banner=uhmet&satplat=goeswest&overlay=off > > http://www.prh.noaa.gov/cphc > > http://www.prh.noaa.gov/cphc/tc_graphics/2014/sat/probCP022014_141017_2030_sata.gif well, clearly it has hit the hawaii.edu site :) but all ok so far up in hawi rady From jra at baylink.com Sat Oct 18 16:02:40 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 18 Oct 2014 12:02:40 -0400 Subject: Major California Faults Ready To Rupture | IFLScience Message-ID: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> Since the last time we had a really major earthquake in California predates the rise of the Internet, this will be the first time for us. What happens when the fault lets go, folks? http://www.iflscience.com/environment/Major-California-Faults-Ready-To-Rupture -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From george.herbert at gmail.com Sat Oct 18 17:20:30 2014 From: george.herbert at gmail.com (George Herbert) Date: Sat, 18 Oct 2014 10:20:30 -0700 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> Message-ID: <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> You should restate the "predates"; I was on console on earthquake.berkeley.edu at the time Loma Prieta let go, using among other things (then) Forumnet (now) ICB in a chat, and one of the immediate damage indications was that everyone at UC Santa Cruz dropped offline. Topic important, though, I live near the Hayward Fault now, and all my customers and most of their data are in the shake zone. George William Herbert Sent from my iPhone > On Oct 18, 2014, at 9:02 AM, Jay Ashworth wrote: > > Since the last time we had a really major earthquake in California predates the rise of the Internet, this will be the first time for us. What happens when the fault lets go, folks? > > http://www.iflscience.com/environment/Major-California-Faults-Ready-To-Rupture > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Sat Oct 18 17:30:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 18 Oct 2014 13:30:09 -0400 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> Message-ID: No I should just clarify that by "rise of the Internet", I meant the internet becoming a part of everyday life and the utility. Which didn't happen until about 96. On October 18, 2014 1:20:30 PM EDT, George Herbert wrote: >You should restate the "predates"; I was on console on >earthquake.berkeley.edu at the time Loma Prieta let go, using among >other things (then) Forumnet (now) ICB in a chat, and one of the >immediate damage indications was that everyone at UC Santa Cruz dropped >offline. > >Topic important, though, I live near the Hayward Fault now, and all my >customers and most of their data are in the shake zone. > > >George William Herbert >Sent from my iPhone > >> On Oct 18, 2014, at 9:02 AM, Jay Ashworth wrote: >> >> Since the last time we had a really major earthquake in California >predates the rise of the Internet, this will be the first time for us. >What happens when the fault lets go, folks? >> >> >http://www.iflscience.com/environment/Major-California-Faults-Ready-To-Rupture >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From surfer at mauigateway.com Sat Oct 18 19:20:37 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 18 Oct 2014 12:20:37 -0700 Subject: hawaii hurricane [was] Re: fema.net dnssec issues Message-ID: <20141018122037.11DDCD52@m0048141.ppops.net> --- randy at psg.com wrote: From: Randy Bush > http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&period=720&incr=30&rr=900&banner=uhmet&satplat=goeswest&overlay=off > > http://www.prh.noaa.gov/cphc > > http://www.prh.noaa.gov/cphc/tc_graphics/2014/sat/probCP022014_141017_2030_sata.gif well, clearly it has hit the hawaii.edu site :) but all ok so far up in hawi ------------------------------------------------------------- It hasn't gotten here yet, but it's not too bad on the northern end of the archipelago either, so DR plans seem to be getting a sort of dry run. I can't imagine a closer miss, though. http://www.ssd.noaa.gov/goes/west/cpac/flash-vis.html scott From woody at pch.net Sat Oct 18 19:22:58 2014 From: woody at pch.net (Bill Woodcock) Date: Sun, 19 Oct 2014 04:22:58 +0900 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> Message-ID: <83239073-A499-4E42-8BDE-956566340706@pch.net> On Oct 19, 2014, at 2:20 AM, George Herbert wrote: > You should restate the "predates"; I was on console on earthquake.berkeley.edu at the time Loma Prieta let go, using among other things (then) Forumnet (now) ICB in a chat, and one of the immediate damage indications was that everyone at UC Santa Cruz dropped offline. …and I was one of those people at UCSC, who had an interesting little adventure driving home to Berkeley the next day. Also, there are probably people in Northridge and Napa who might dispute your definition of “major,” but yes,a I take your point. http://en.wikipedia.org/wiki/1994_Northridge_earthquake http://en.wikipedia.org/wiki/2010_Baja_California_earthquake http://en.wikipedia.org/wiki/2014_South_Napa_earthquake -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Sat Oct 18 20:06:27 2014 From: randy at psg.com (Randy Bush) Date: Sat, 18 Oct 2014 13:06:27 -0700 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> Message-ID: > You should restate the "predates" Kenjiro Cho, Cristel Pelsser, Randy Bush, Youngjoon Won, The Japan Earthquake: the impact on traffic and routing observed by a local ISP, ACM CoNEXT 2011 Special Workshop on the Internet and Disasters. December 6, 2011. http://archive.psg.com/111206.conext-quake.pdf From jra at baylink.com Sat Oct 18 21:18:35 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 18 Oct 2014 17:18:35 -0400 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <83239073-A499-4E42-8BDE-956566340706@pch.net> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> Message-ID: <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> How widespread were the effects on backbone communication circuits from those quakes? On October 18, 2014 3:22:58 PM EDT, Bill Woodcock wrote: > >On Oct 19, 2014, at 2:20 AM, George Herbert >wrote: > >> You should restate the "predates"; I was on console on >earthquake.berkeley.edu at the time Loma Prieta let go, using among >other things (then) Forumnet (now) ICB in a chat, and one of the >immediate damage indications was that everyone at UC Santa Cruz dropped >offline. > >…and I was one of those people at UCSC, who had an interesting little >adventure driving home to Berkeley the next day. > >Also, there are probably people in Northridge and Napa who might >dispute your definition of “major,” but yes,a I take your point. > >http://en.wikipedia.org/wiki/1994_Northridge_earthquake > >http://en.wikipedia.org/wiki/2010_Baja_California_earthquake > >http://en.wikipedia.org/wiki/2014_South_Napa_earthquake > > -Bill -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From woody at pch.net Sat Oct 18 22:42:59 2014 From: woody at pch.net (Bill Woodcock) Date: Sun, 19 Oct 2014 07:42:59 +0900 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> Message-ID: <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> Nothing that I recall. Sean might know better. -Bill > On Oct 19, 2014, at 6:19, "Jay Ashworth" wrote: > > How widespread were the effects on backbone communication circuits from those quakes? > >> On October 18, 2014 3:22:58 PM EDT, Bill Woodcock wrote: >> >>> On Oct 19, 2014, at 2:20 AM, George Herbert wrote: >>> >>> You should restate the "predates"; I was on console on earthquake.berkeley.edu at the time Loma Prieta let go, using among other things (then) Forumnet (now) ICB in a chat, and one of the immediate damage indications was that everyone at UC Santa Cruz dropped offline. >> >> …and I was one of those people at UCSC, who had an interesting little adventure driving home to Berkeley the next day. >> >> Also, there are probably people in Northridge and Napa who might dispute your definition of “major,” but yes,a I take your point. >> >> http://en.wikipedia.org/wiki/1994_Northridge_earthquake >> >> http://en.wikipedia.org/wiki/2010_Baja_California_earthquake >> >> http://en.wikipedia.org/wiki/2014_South_Napa_earthquake >> >> -Bill > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From chris at aperturefiber.com Sat Oct 18 23:22:42 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Sat, 18 Oct 2014 18:22:42 -0500 Subject: Singtel NOC contacts Message-ID: I know it is a long shot, but if someone could contact me off list from the Singtel NOC, I would be most appreciative. From george.herbert at gmail.com Sun Oct 19 07:45:50 2014 From: george.herbert at gmail.com (George Herbert) Date: Sun, 19 Oct 2014 00:45:50 -0700 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> Message-ID: Loma Prieta, very little; the UCSC line was a non-redundant T1 from San Jose BARRNET, and the other leaf nodes off that were down. As I recall the San Jose / SF to LA links were all golden. Phone service to Santa Cruz was down, then spotty, then up over the course of a day, but every line was jammed with people checking in so connect rates sucked. The UCSC point to point T1 had to be manually repaired I think. The telco lines had alternate routes for calls and made it work, in a bit. Northridge a few years later more or less flattened a C&W center just about at ground zero. CRL's pager-happy 24x7 MUD customer in Atlanta woke me up a minute later, and our lines through LA (and many others' lines) were down for a while. Dynamic routing was a little less dynamic then; I don't know what others did in great detail. CIX lists buzzed etc. I think that predates nanog as a list by a few months, but memory is fuzzy. George William Herbert Sent from my iPhone > On Oct 18, 2014, at 3:42 PM, "Bill Woodcock" wrote: > > Nothing that I recall. Sean might know better. > > > -Bill > > >> On Oct 19, 2014, at 6:19, "Jay Ashworth" wrote: >> >> How widespread were the effects on backbone communication circuits from those quakes? >> >>> On October 18, 2014 3:22:58 PM EDT, Bill Woodcock wrote: >>> >>>> On Oct 19, 2014, at 2:20 AM, George Herbert wrote: >>>> >>>> You should restate the "predates"; I was on console on earthquake.berkeley.edu at the time Loma Prieta let go, using among other things (then) Forumnet (now) ICB in a chat, and one of the immediate damage indications was that everyone at UC Santa Cruz dropped offline. >>> >>> …and I was one of those people at UCSC, who had an interesting little adventure driving home to Berkeley the next day. >>> >>> Also, there are probably people in Northridge and Napa who might dispute your definition of “major,” but yes,a I take your point. >>> >>> http://en.wikipedia.org/wiki/1994_Northridge_earthquake >>> >>> http://en.wikipedia.org/wiki/2010_Baja_California_earthquake >>> >>> http://en.wikipedia.org/wiki/2014_South_Napa_earthquake >>> >>> -Bill >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. From lear at cisco.com Sun Oct 19 09:03:49 2014 From: lear at cisco.com (Eliot Lear) Date: Sun, 19 Oct 2014 11:03:49 +0200 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> Message-ID: <54437E75.4080100@cisco.com> On 10/19/14, 9:45 AM, George Herbert wrote: > Loma Prieta, very little; the UCSC line was a non-redundant T1 from San Jose BARRNET, and the other leaf nodes off that were down. As I recall the San Jose / SF to LA links were all golden. > > Phone service to Santa Cruz was down, then spotty, then up over the course of a day, but every line was jammed with people checking in so connect rates sucked. The UCSC point to point T1 had to be manually repaired I think. The telco lines had alternate routes for calls and made it work, in a bit. > This was my recollection as well. Many corporate PBXes failed, and as it happened, for some reason, the mobile towers functioned with excess capacity, to the point where I had a line coming out of my car. Best form of communication into and out of the region during the crisis was the Internet. No surprise. That's what it was designed for. Eliot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 486 bytes Desc: OpenPGP digital signature URL: From pete at altadena.net Sun Oct 19 09:38:12 2014 From: pete at altadena.net (Pete Carah) Date: Sun, 19 Oct 2014 04:38:12 -0500 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> Message-ID: <54438684.6030909@altadena.net> On 10/19/2014 02:45 AM, George Herbert wrote: > Loma Prieta, very little; the UCSC line was a non-redundant T1 from San Jose BARRNET, and the other leaf nodes off that were down. As I recall the San Jose / SF to LA links were all golden. > > Phone service to Santa Cruz was down, then spotty, then up over the course of a day, but every line was jammed with people checking in so connect rates sucked. The UCSC point to point T1 had to be manually repaired I think. The telco lines had alternate routes for calls and made it work, in a bit. > > Northridge a few years later more or less flattened a C&W center just about at ground zero. CRL's pager-happy 24x7 MUD customer in Atlanta woke me up a minute later, and our lines through LA (and many others' lines) were down for a while. Dynamic routing was a little less dynamic then; I don't know what others did in great detail. > > CIX lists buzzed etc. I think that predates nanog as a list by a few months, but memory is fuzzy. > > > George William Herbert > Sent from my iPhone > Northridge cut a section out of the Santa Monica freeway, which took out a bunch of cable (I think by then it was mostly fiber) between USC and points west; that got Cerfnet's connections to several west LA customers (I worked for one of them in Culver City at the time). I kind of remember that they restored it by routing through Los Nettos. At home I was using the Cerfnet Caltech pop at the time, and had an outage for an hour or two (and lost power for about that long). The windstorm a few years later cut lots of above-ground fiber, though; lots more outages than any earthquake. I recall that CSUN was pretty well cut off (both net and roads) for a while. I don't recall if the Hector Mine quake cut any fiber but there is a repeater building near the railroad just east of the fault-line crossing. There wasn't a ground break that far north so the cables probably weathered it OK but the building might not have. (amazing to have a 7.4 or so quake that almost didn't injure anyone; almost all the damage was from the derail of the southwest chief westbound.) From mpetach at netflight.com Sun Oct 19 12:05:01 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 19 Oct 2014 05:05:01 -0700 Subject: Why is .gov only for US government agencies? Message-ID: Wondering if some of the long-time list members can shed some light on the question--why is the .gov top level domain only for use by US government agencies? Where do other world powers put their government agency domains? With the exception of the cctlds, shouldn't the top-level gtlds be generically open to anyone regardless of borders? Would love to get any info about the history of the decision to make it US-only. Thanks! Matt From sthaug at nethelp.no Sun Oct 19 12:12:22 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 19 Oct 2014 14:12:22 +0200 (CEST) Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <20141019.141222.78790245.sthaug@nethelp.no> > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? Do you have reason to believe that governments of other countries would *want* to use the .gov TLD? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Sun Oct 19 12:12:59 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 19 Oct 2014 07:12:59 -0500 (CDT) Subject: Why is .gov only for US government agencies? In-Reply-To: Message-ID: <201410191212.s9JCCx5T037652@aurora.sol.net> > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? > > Would love to get any info about the history > of the decision to make it US-only. In part due to RFC1480. At one point, everything here in the US was set to transition away from the US- and TLD-centric models. It is now only a fuzzy memory, but at one point commercial entities could not just register a random .NET or .ORG domain name ... which would have resulted in a nicer-looking Internet domain system today. But to make a long story short, and my memory's perhaps a bit rusty now, but my recollection is that shorter URL's looked nicer and there was significant money to be had running the registry, so there was some heavy lobbying against retiring .GOV in favor of .FED.US (and other .US locality domains). ... 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 d3e3e3 at gmail.com Sun Oct 19 12:42:13 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 19 Oct 2014 08:42:13 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: Why is the Greek flag always flow at the Olympics as well as the Olympic and host nation flags? Why is Britain the only country allowed, under Universal Postal Union regulations to have no national identification on its stamps used in international mail? Basically, if you are first, you tend to get extra privileges. Same with .gov for the US government. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Sun, Oct 19, 2014 at 8:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? > > Would love to get any info about the history > of the decision to make it US-only. > > Thanks! > > Matt From mysidia at gmail.com Sun Oct 19 13:13:10 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 19 Oct 2014 08:13:10 -0500 Subject: Why is .gov only for US government agencies? In-Reply-To: <201410191212.s9JCCx5T037652@aurora.sol.net> References: <201410191212.s9JCCx5T037652@aurora.sol.net> Message-ID: On Sun, Oct 19, 2014 at 7:12 AM, Joe Greco wrote: > But to make a long story short, and my memory's perhaps a bit rusty > now, but my recollection is that shorter URL's looked nicer and there > was significant money to be had running the registry, so there was > some heavy lobbying against retiring .GOV in favor of .FED.US (and > other .US locality domains). [snip] The same problem exists with .EDU capriciously adopting new criteria that excludes any non-US-based institutions from being eligible. I believe the major issue is that if a TLD is in the global namespace, then it should NOT be allowed to restrict registrations based on country; the internet is global and .GOV and .EDU are in Global Namespace. So then, why aren't .EDU and .GOV just allowed to continue to exist but a community decision made to require whichever registry will be contracted to manage .GOV to accept registrations from _all_ government entities regardless of nationality ? In otherwords, rejection of the idea that a registry operating GTLD namespace can be allowed to impose overly exclusive "eligibility criteria" > ... JG -- -JH From paigeadele at gmail.com Sun Oct 19 13:15:10 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Sun, 19 Oct 2014 13:15:10 +0000 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <5443B95E.104@gmail.com> On 10/19/14 12:42, Donald Eastlake wrote: > Why is the Greek flag always flow at the Olympics as well as the > Olympic and host nation flags? Why is Britain the only country > allowed, under Universal Postal Union regulations to have no national > identification on its stamps used in international mail? Basically, if > you are first, you tend to get extra privileges. Same with .gov for > the US government. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3 at gmail.com > > > On Sun, Oct 19, 2014 at 8:05 AM, Matthew Petach wrote: >> Wondering if some of the long-time list members >> can shed some light on the question--why is the >> .gov top level domain only for use by US >> government agencies? Where do other world >> powers put their government agency domains? >> >> With the exception of the cctlds, shouldn't the >> top-level gtlds be generically open to anyone >> regardless of borders? >> >> Would love to get any info about the history >> of the decision to make it US-only. >> >> Thanks! >> >> Matt Do as we say, not as we do From jgreco at ns.sol.net Sun Oct 19 13:20:37 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 19 Oct 2014 08:20:37 -0500 (CDT) Subject: Why is .gov only for US government agencies? In-Reply-To: Message-ID: <201410191320.s9JDKbA9038487@aurora.sol.net> > On Sun, Oct 19, 2014 at 7:12 AM, Joe Greco wrote: > > But to make a long story short, and my memory's perhaps a bit rusty > > now, but my recollection is that shorter URL's looked nicer and there > > was significant money to be had running the registry, so there was > > some heavy lobbying against retiring .GOV in favor of .FED.US (and > > other .US locality domains). > [snip] > > The same problem exists with .EDU capriciously adopting new criteria > that excludes any non-US-based institutions from being eligible. I > believe the major issue is that if a TLD is in the global namespace, > then it should NOT be allowed to restrict registrations based on > country; the internet is global and .GOV and .EDU are in Global > Namespace. > > So then, why aren't .EDU and .GOV just allowed to continue to exist > but a community decision made to require whichever registry will be > contracted to manage .GOV to accept registrations from _all_ > government entities regardless of nationality ? Because the US has historically held control over the whole process. Regardless of what it may seem like, it's not a community process. > In otherwords, rejection of the idea that a registry operating GTLD > namespace can be allowed to impose overly exclusive "eligibility > criteria" In the specific case of ".gov", I'd say that there's some danger to having multiple nations operating in that single 2LD space; .gov should probably be retired and federal institutions migrated to .fed.us. There's also namespace available for localities. But given the choice between rationality and insanity, usually the process seems to prefer insanity. ... 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 the.lists at mgm51.com Sun Oct 19 13:51:27 2014 From: the.lists at mgm51.com (Mike.) Date: Sun, 19 Oct 2014 09:51:27 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> Message-ID: <201410190951270460.00404B14@smtp.24cl.home> On 10/19/2014 at 8:13 AM Jimmy Hess wrote: |[snip] |So then, why aren't .EDU and .GOV just allowed to continue to exist |but a community decision made to require whichever registry will be |contracted to manage .GOV to accept registrations from _all_ |government entities regardless of nationality ? | |In otherwords, rejection of the idea that a registry operating GTLD |namespace can be allowed to impose overly exclusive "eligibility |criteria" ============= I'd rather see .gov (and by implication, .edu) usage phased out and replaced by country-specific domain names (e.g. fed.us). imo, the better way to fix an anachronism is not to bend the rules so the offenders are not so offensive, but to bring the offenders into compliance with the current rules. From mehmet at akcin.net Sun Oct 19 14:00:45 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 19 Oct 2014 07:00:45 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> Message-ID: <3B741C6C-818D-4196-89C6-FC402685EE34@akcin.net> you can register .edu if you are a non-us institution as long as you are accredited by a US recognized organization Mehmet > On Oct 19, 2014, at 6:13 AM, Jimmy Hess wrote: > >> On Sun, Oct 19, 2014 at 7:12 AM, Joe Greco wrote: >> >> But to make a long story short, and my memory's perhaps a bit rusty >> now, but my recollection is that shorter URL's looked nicer and there >> was significant money to be had running the registry, so there was >> some heavy lobbying against retiring .GOV in favor of .FED.US (and >> other .US locality domains). > [snip] > > The same problem exists with .EDU capriciously adopting new criteria > that excludes any non-US-based institutions from being eligible. I > believe the major issue is that if a TLD is in the global namespace, > then it should NOT be allowed to restrict registrations based on > country; the internet is global and .GOV and .EDU are in Global > Namespace. > > So then, why aren't .EDU and .GOV just allowed to continue to exist > but a community decision made to require whichever registry will be > contracted to manage .GOV to accept registrations from _all_ > government entities regardless of nationality ? > > In otherwords, rejection of the idea that a registry operating GTLD > namespace can be allowed to impose overly exclusive "eligibility > criteria" > > >> ... JG > > -- > -JH From johnl at iecc.com Sun Oct 19 14:32:59 2014 From: johnl at iecc.com (John Levine) Date: 19 Oct 2014 14:32:59 -0000 Subject: Why is .gov only for US government agencies? In-Reply-To: Message-ID: <20141019143259.3439.qmail@ary.lan> >The same problem exists with .EDU capriciously adopting new criteria >that excludes any non-US-based institutions from being eligible. I >believe the major issue is that if a TLD is in the global namespace, >then it should NOT be allowed to restrict registrations based on >country; the internet is global and .GOV and .EDU are in Global >Namespace. Gee, someone should alert NANOG management that the list has fallen through a wormhole into 1996. To answer the original question, many governments use a subdomain of their ccTLD such as gc.ca or gov.uk. Or they just use a name directly in the ccTLD such as bundesregierung.de. R's, John From list at satchell.net Sun Oct 19 15:21:34 2014 From: list at satchell.net (Stephen Satchell) Date: Sun, 19 Oct 2014 08:21:34 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <201410191320.s9JDKbA9038487@aurora.sol.net> References: <201410191320.s9JDKbA9038487@aurora.sol.net> Message-ID: <5443D6FE.4060008@satchell.net> On 10/19/2014 06:20 AM, Joe Greco wrote: > But given the choice between rationality and insanity, usually the > process seems to prefer insanity. Or, alternatively, inertia. I would be like renumbering, only worse, because so many links would need to be found and updated. From nanog at shankland.org Sun Oct 19 15:44:10 2014 From: nanog at shankland.org (Jim Shankland) Date: Sun, 19 Oct 2014 08:44:10 -0700 Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <54437E75.4080100@cisco.com> References: <94ec99de-d147-4f5c-a92a-eb49eae4413d@email.android.com> <368BD1C0-D746-4E85-B0B6-1E62AE8784EA@gmail.com> <83239073-A499-4E42-8BDE-956566340706@pch.net> <6f4c46e9-d010-4c63-9540-f413f56c8825@email.android.com> <6D85E416-EAE5-46B7-9F86-C8765A3DB655@pch.net> <54437E75.4080100@cisco.com> Message-ID: <5443DC4A.2090101@shankland.org> On 10/19/14 2:03 AM, Eliot Lear wrote: > This was my recollection as well. Many corporate PBXes failed, and as > it happened, for some reason, the mobile towers functioned with excess > capacity, to the point where I had a line coming out of my car. Best > form of communication into and out of the region during the crisis was > the Internet. No surprise. That's what it was designed for. > So I guess heartbeat.belkin.com stayed up? Jim From fmartin at linkedin.com Sun Oct 19 16:21:15 2014 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 19 Oct 2014 16:21:15 +0000 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> Message-ID: On Oct 19, 2014, at 9:13 AM, Jimmy Hess wrote: > On Sun, Oct 19, 2014 at 7:12 AM, Joe Greco wrote: > >> But to make a long story short, and my memory's perhaps a bit rusty >> now, but my recollection is that shorter URL's looked nicer and there >> was significant money to be had running the registry, so there was >> some heavy lobbying against retiring .GOV in favor of .FED.US (and >> other .US locality domains). > [snip] > > The same problem exists with .EDU capriciously adopting new criteria > that excludes any non-US-based institutions from being eligible. I > believe the major issue is that if a TLD is in the global namespace, > then it should NOT be allowed to restrict registrations based on > country; the internet is global and .GOV and .EDU are in Global > Namespace. > > So then, why aren't .EDU and .GOV just allowed to continue to exist > but a community decision made to require whichever registry will be > contracted to manage .GOV to accept registrations from _all_ > government entities regardless of nationality ? > You forgot .MIL , this one will be even more fun to change... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rubensk at gmail.com Sun Oct 19 16:35:17 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 19 Oct 2014 14:35:17 -0200 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: On Sun, Oct 19, 2014 at 10:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > Note that .mil is also restricted to US DoD, and that although .com is not restricted to US citizens and companies, it is under contract with US DoC. The only legacy gTLDs that are not in US control of some sort are .net and .org. Rubens From drc at virtualized.org Sun Oct 19 16:51:12 2014 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Oct 2014 09:51:12 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <6B6F4C88-EBD6-4207-8666-879EA0C1F0B8@virtualized.org> On Oct 19, 2014, at 9:35 AM, Rubens Kuhl wrote: >> Wondering if some of the long-time list members >> can shed some light on the question--why is the >> .gov top level domain only for use by US >> government agencies? RFC 1591. >> Where do other world >> powers put their government agency domains? Under their ccTLDs. > Note that .mil is also restricted to US DoD, Yes. See RFC 1591. > and that although .com is not > restricted to US citizens and companies, it is under contract with US DoC. > The only legacy gTLDs that are not in US control of some sort are .net and > .org. No. NET is under essentially the same contractual agreement as .COM (specifically, Cooperative Agreement NCR-9218742). By the terms of Amendment 24 of that CA, ORG was removed from the CA when that registry moved to PIR (in 2002 I believe). Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jimpop at gmail.com Sun Oct 19 16:57:06 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 19 Oct 2014 12:57:06 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <6B6F4C88-EBD6-4207-8666-879EA0C1F0B8@virtualized.org> References: <6B6F4C88-EBD6-4207-8666-879EA0C1F0B8@virtualized.org> Message-ID: On Sun, Oct 19, 2014 at 12:51 PM, David Conrad wrote: > RFC 1591. "It is extremely unlikely that any other TLDs will be created." My how times have changed. -Jim P. From colton.conor at gmail.com Sun Oct 19 22:34:53 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 19 Oct 2014 17:34:53 -0500 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: So it looks like DOCSIS cable has a great solution with IPDR, but what about DSL, GPON, and regular Ethernet networks? It was mentioned that DSL uses radius, but most new DSL systems no longer use PPPoE, so I don't believe radius is a viable option. What about Wifi Access Points? What would be the best way to track usage across these devices? On Wed, Oct 15, 2014 at 3:33 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > There are lots of ways to do it. Cable uses IPDR, which is baked into > DOCSIS standards. > http://en.wikipedia.org/wiki/Internet_Protocol_Detail_Record > > > > On 10/15/14, 1:38 PM, "Colton Conor" wrote: > > >So based on the response I have received so far it seems cable was a > >complicated example with service flows involved. What if we are talking > >about something simpler like keeping track of how much data flows in and > >out of a port on a switch in a given month? I know you can use SNMP, but I > >believe that polls in intervals and takes samples which isn't really > >accurate right? > > > >On Wed, Oct 15, 2014 at 1:40 PM, wrote: > > > >> Folks, use sflow with rrdtool! > >> > >> Quite awesome & handy > >> > >> On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: > >> > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> > > >> >> on a cisco switch vs a DSL port on a DSLAM for example? I would think > >> these > >> >> access switches would have some sort of stat you can count similar > >>to a > >> >> utility meter reader on a house. See what it was at last month, see > >> what is > >> >> is at this month, subtract last months from this months, and the > >> difference > >> >> is the total amount used for that month. > >> > > >> > Assume a 20mbit connection. How many times can this roll over a > >> > 32 bit counter in a month if it's going full blast? > >> > > >> > >> > > From aj at sneep.net Mon Oct 20 01:58:17 2014 From: aj at sneep.net (Alastair Johnson) Date: Sun, 19 Oct 2014 18:58:17 -0700 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: <20141020015817.5877909.95359.43791@sneep.net> There's no correlation between PPPoE and RADIUS. Many (if not all) BRAS/BNG platforms will support RADIUS based accounting for IPoE sessions. The majority of accounting is done that way; with outliers using some other mechanism (Diameter; proprietary vendor billing solutions; flow based platforms; or counters elsewhere on the network). WiFi in my experience also typically uses a RADIUS based approach, although it can depend on the deployment context. AJ   Original Message   From: Colton Conor Sent: Sunday, October 19, 2014 3:35 PM To: Livingood, Jason Cc: NANOG Subject: Re: Keeping Track of Data Usage in GB Per Port So it looks like DOCSIS cable has a great solution with IPDR, but what about DSL, GPON, and regular Ethernet networks? It was mentioned that DSL uses radius, but most new DSL systems no longer use PPPoE, so I don't believe radius is a viable option. What about Wifi Access Points? What would be the best way to track usage across these devices? On Wed, Oct 15, 2014 at 3:33 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > There are lots of ways to do it. Cable uses IPDR, which is baked into > DOCSIS standards. > http://en.wikipedia.org/wiki/Internet_Protocol_Detail_Record > > > > On 10/15/14, 1:38 PM, "Colton Conor" wrote: > > >So based on the response I have received so far it seems cable was a > >complicated example with service flows involved. What if we are talking > >about something simpler like keeping track of how much data flows in and > >out of a port on a switch in a given month? I know you can use SNMP, but I > >believe that polls in intervals and takes samples which isn't really > >accurate right? > > > >On Wed, Oct 15, 2014 at 1:40 PM, wrote: > > > >> Folks, use sflow with rrdtool! > >> > >> Quite awesome & handy > >> > >> On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: > >> > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> > > >> >> on a cisco switch vs a DSL port on a DSLAM for example? I would think > >> these > >> >> access switches would have some sort of stat you can count similar > >>to a > >> >> utility meter reader on a house. See what it was at last month, see > >> what is > >> >> is at this month, subtract last months from this months, and the > >> difference > >> >> is the total amount used for that month. > >> > > >> > Assume a 20mbit connection. How many times can this roll over a > >> > 32 bit counter in a month if it's going full blast? > >> > > >> > >> > > From jra at baylink.com Mon Oct 20 02:52:13 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Oct 2014 22:52:13 -0400 (EDT) Subject: Major California Faults Ready To Rupture | IFLScience In-Reply-To: <5443DC4A.2090101@shankland.org> Message-ID: <7891144.6289.1413773533453.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jim Shankland" > On 10/19/14 2:03 AM, Eliot Lear wrote: > > This was my recollection as well. Many corporate PBXes failed, and as > > it happened, for some reason, the mobile towers functioned with excess > > capacity, to the point where I had a line coming out of my car. Best > > form of communication into and out of the region during the crisis > > was the Internet. No surprise. That's what it was designed for. > > So I guess heartbeat.belkin.com stayed up? And Jim wins the Internet for this weekend. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From swmike at swm.pp.se Mon Oct 20 04:09:25 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Oct 2014 06:09:25 +0200 (CEST) Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: On Wed, 15 Oct 2014, Colton Conor wrote: > So based on the response I have received so far it seems cable was a > complicated example with service flows involved. What if we are talking > about something simpler like keeping track of how much data flows in and > out of a port on a switch in a given month? I know you can use SNMP, but I > believe that polls in intervals and takes samples which isn't really > accurate right? If you're measuring per month, there is no reason you can't use SNMP, poll that 64bit counter once per day or something, and then add the values up each month. It'll be accurate enough. SNMP isn't sampled, if you poll the IfOctet counter, it just counts upwards and if you're not worried about the switch rebooting, you could poll it once per month and be accurate. I'd say polling it once or a few times a day protects enough against that. -- Mikael Abrahamsson email: swmike at swm.pp.se From skeeve+nanog at eintellegonetworks.com Mon Oct 20 04:55:10 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Mon, 20 Oct 2014 15:55:10 +1100 Subject: ISP Shaping Hardware Message-ID: Hey all, Just wondering what/if people are using any shaping hardware/appliances these days, and if so, what. I have a client which has thousands of customers on Satellite and needs to restrict some users who are doing a lot. So I wanted to see what the current popular equipment out there is. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering From william.allen.simpson at gmail.com Mon Oct 20 06:27:00 2014 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 20 Oct 2014 02:27:00 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <6B6F4C88-EBD6-4207-8666-879EA0C1F0B8@virtualized.org> References: <6B6F4C88-EBD6-4207-8666-879EA0C1F0B8@virtualized.org> Message-ID: <5444AB34.9070607@gmail.com> On 10/19/14 10:32 AM, John Levine wrote: # Gee, someone should alert NANOG management that the list has fallen # through a wormhole into 1996. # On 10/19/14 12:51 PM, David Conrad wrote: > RFC 1591. > Which is circa 1994. The real answer is that although fed.us is used by some agencies, the overall requirement was stripped out of the Telecommunications Act of 1996. Basically, the DC area incumbent provider of .gov and .com was making so insanely much money per registration, they were able to buy off persuade enough politicians to keep their monopolistic status. Slowly, slowly, technical progress (Google) and cooperative agreements have eroded that "land grab" into an oligopoly instead. From ag4ve.us at gmail.com Mon Oct 20 09:58:01 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 05:58:01 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <201410190951270460.00404B14@smtp.24cl.home> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> Message-ID: On Oct 19, 2014 9:53 AM, "Mike." wrote: > > > I'd rather see .gov (and by implication, .edu) usage phased out and > replaced by country-specific domain names (e.g. fed.us). > > imo, the better way to fix an anachronism is not to bend the rules so > the offenders are not so offensive, but to bring the offenders into > compliance with the current rules. > Bad idea. I'm betting we'd find half of gov web sites down due to not being able to reboot and issues in old coldfusion and IIS and the like (and needing to fix static links and testing etc). No, if it ain't broke don't fix it. From rdobbins at arbor.net Mon Oct 20 10:12:52 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 20 Oct 2014 17:12:52 +0700 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: <-3244860566046223771@unknownmsgid> On Oct 20, 2014, at 11:56 AM, Skeeve Stevens < skeeve+nanog at eintellegonetworks.com> wrote: I have a client which has thousands of customers on Satellite and needs to restrict some users who are doing a lot. Is QoS in the network infrastructure coupled with strictly-enforced quotas insufficient to needs? These permanently-inline boxes and blades that dork around with general Internet traffic to/from eyeball networks can be a support/troubleshooting headache . . . ----------------------------------- Roland Dobbins From nick at foobar.org Mon Oct 20 10:57:03 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 20 Oct 2014 11:57:03 +0100 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <5444EA7F.2000504@foobar.org> On 19/10/2014 13:05, Matthew Petach wrote: > Would love to get any info about the history > of the decision to make it US-only. incidentally, why does the .gov SOA list usadotgov.net in its SOA? The web site for the domain looks like it's copied from drjanicepostal.com. Has USGOV decided to open a new executive branch for podiatry? Nick From nick at foobar.org Mon Oct 20 11:08:29 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 20 Oct 2014 12:08:29 +0100 Subject: ISP Shaping Hardware In-Reply-To: <-3244860566046223771@unknownmsgid> References: <-3244860566046223771@unknownmsgid> Message-ID: <5444ED2D.3030800@foobar.org> On 20/10/2014 11:12, Roland Dobbins wrote: > Is QoS in the network infrastructure coupled with strictly-enforced quotas > insufficient to needs? for satellite, no. > These permanently-inline boxes and blades that dork around with general > Internet traffic to/from eyeball networks can be a support/troubleshooting > headache . . . s/headache/nightmare/ The high latency and bandwidth costs on satellite connections are a world of pain. It should show how awful things are when you can actually improve things by installing inline bandwidth accelerators and traffic shapers. Nick From nurul at apnic.net Mon Oct 20 11:31:26 2014 From: nurul at apnic.net (Nurul Islam Roman) Date: Mon, 20 Oct 2014 11:31:26 +0000 Subject: ISP Shaping Hardware In-Reply-To: Message-ID: Used following two product to shape traffic on packet level (L3). Had no issue with several thousand customer. Allot http://www.allot.com/netenforcer.html ET http://www.etinc.com/ Found "Allot" is very popular for satellite based Internet specially in south pacific island countries. -R On 20/10/14 2:55 PM, "Skeeve Stevens" wrote: >Hey all, > >Just wondering what/if people are using any shaping hardware/appliances >these days, and if so, what. > >I have a client which has thousands of customers on Satellite and needs to >restrict some users who are doing a lot. > >So I wanted to see what the current popular equipment out there is. > >...Skeeve > >*Skeeve Stevens - *eintellego Networks Pty Ltd >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > >facebook.com/eintellegonetworks ; >linkedin.com/in/skeeve > >experts360: https://expert360.com/profile/d54a9 > >twitter.com/theispguy ; blog: www.theispguy.com > > >The Experts Who The Experts Call >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4598 bytes Desc: not available URL: From frnkblk at iname.com Mon Oct 20 12:00:46 2014 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 20 Oct 2014 07:00:46 -0500 Subject: Keeping Track of Data Usage in GB Per Port In-Reply-To: References: <2990.1413396871@turing-police.cc.vt.edu> <543EBFA3.4080002@jack.fr.eu.org> Message-ID: <004501cfec5d$7bf17890$73d469b0$@iname.com> For GPON and Ethernet it's just SNMP counters. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Sunday, October 19, 2014 5:35 PM To: Livingood, Jason Cc: NANOG Subject: Re: Keeping Track of Data Usage in GB Per Port So it looks like DOCSIS cable has a great solution with IPDR, but what about DSL, GPON, and regular Ethernet networks? It was mentioned that DSL uses radius, but most new DSL systems no longer use PPPoE, so I don't believe radius is a viable option. What about Wifi Access Points? What would be the best way to track usage across these devices? On Wed, Oct 15, 2014 at 3:33 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > There are lots of ways to do it. Cable uses IPDR, which is baked into > DOCSIS standards. > http://en.wikipedia.org/wiki/Internet_Protocol_Detail_Record > > > > On 10/15/14, 1:38 PM, "Colton Conor" wrote: > > >So based on the response I have received so far it seems cable was a > >complicated example with service flows involved. What if we are talking > >about something simpler like keeping track of how much data flows in and > >out of a port on a switch in a given month? I know you can use SNMP, but I > >believe that polls in intervals and takes samples which isn't really > >accurate right? > > > >On Wed, Oct 15, 2014 at 1:40 PM, wrote: > > > >> Folks, use sflow with rrdtool! > >> > >> Quite awesome & handy > >> > >> On 15/10/2014 20:14, Valdis.Kletnieks at vt.edu wrote: > >> > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> > > >> >> on a cisco switch vs a DSL port on a DSLAM for example? I would think > >> these > >> >> access switches would have some sort of stat you can count similar > >>to a > >> >> utility meter reader on a house. See what it was at last month, see > >> what is > >> >> is at this month, subtract last months from this months, and the > >> difference > >> >> is the total amount used for that month. > >> > > >> > Assume a 20mbit connection. How many times can this roll over a > >> > 32 bit counter in a month if it's going full blast? > >> > > >> > >> > > From skeeve+nanog at eintellegonetworks.com Mon Oct 20 12:05:13 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Mon, 20 Oct 2014 23:05:13 +1100 Subject: ISP Shaping Hardware In-Reply-To: <-3244860566046223771@unknownmsgid> References: <-3244860566046223771@unknownmsgid> Message-ID: I know and feel the same way Roland. Just trying to figure out the best way to get these users with a scare resource under control. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On 20 October 2014 21:12, Roland Dobbins wrote: > On Oct 20, 2014, at 11:56 AM, Skeeve Stevens < > skeeve+nanog at eintellegonetworks.com> wrote: > > I have a client which has thousands of customers on Satellite and needs to > restrict some users who are doing a lot. > > > Is QoS in the network infrastructure coupled with strictly-enforced quotas > insufficient to needs? > > These permanently-inline boxes and blades that dork around with general > Internet traffic to/from eyeball networks can be a support/troubleshooting > headache . . . > > ----------------------------------- > Roland Dobbins > From itg at itechgeek.com Mon Oct 20 13:06:44 2014 From: itg at itechgeek.com (ITechGeek) Date: Mon, 20 Oct 2014 09:06:44 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <5444EA7F.2000504@foobar.org> References: <5444EA7F.2000504@foobar.org> Message-ID: The name of the game is you create it, you set your own rules. The United States Gov't was involved w/ the Internet before people thought about it being more than just a US gov't system. As far as the SOA, someone probably copied and pasted another SOA not really knowing what they were doing (or copied pasted, saved, modified, forgot to hit save). ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Oct 20, 2014 at 6:57 AM, Nick Hilliard wrote: > On 19/10/2014 13:05, Matthew Petach wrote: > > Would love to get any info about the history > > of the decision to make it US-only. > > incidentally, why does the .gov SOA list usadotgov.net in its SOA? The > web > site for the domain looks like it's copied from drjanicepostal.com. Has > USGOV decided to open a new executive branch for podiatry? > > Nick > > > From rs at seastrom.com Mon Oct 20 13:39:31 2014 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 20 Oct 2014 09:39:31 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <5444EA7F.2000504@foobar.org> (Nick Hilliard's message of "Mon, 20 Oct 2014 11:57:03 +0100") References: <5444EA7F.2000504@foobar.org> Message-ID: <86egu2oo6k.fsf@valhalla.seastrom.com> Nick Hilliard writes: > On 19/10/2014 13:05, Matthew Petach wrote: >> Would love to get any info about the history >> of the decision to make it US-only. > > incidentally, why does the .gov SOA list usadotgov.net in its SOA? The web > site for the domain looks like it's copied from drjanicepostal.com. Has > USGOV decided to open a new executive branch for podiatry? Government's got to keep on its feet. -r From Valdis.Kletnieks at vt.edu Mon Oct 20 14:20:45 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Oct 2014 10:20:45 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: Your message of "Mon, 20 Oct 2014 05:58:01 -0400." References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> Message-ID: <93034.1413814845@turing-police.cc.vt.edu> On Mon, 20 Oct 2014 05:58:01 -0400, shawn wilson said: > Bad idea. I'm betting we'd find half of gov web sites down due to not being > able to reboot and issues in old coldfusion and IIS and the like (and > needing to fix static links and testing etc). You say that like it's a bad thing.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ag4ve.us at gmail.com Mon Oct 20 14:45:44 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 10:45:44 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <93034.1413814845@turing-police.cc.vt.edu> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> Message-ID: On Mon, Oct 20, 2014 at 10:20 AM, wrote: > On Mon, 20 Oct 2014 05:58:01 -0400, shawn wilson said: > >> Bad idea. I'm betting we'd find half of gov web sites down due to not being >> able to reboot and issues in old coldfusion and IIS and the like (and >> needing to fix static links and testing etc). > > You say that like it's a bad thing.... Well yeah, there's tons of possible bad here. 1. Some contractor would get millions over a few years for doing this 2. Spending time to maintain old code that no one cares about just to make stuff work is kinda annoying (both for those maintaining the code and #1) 3. I don't want to see the report on how many Allaire ColdFusion with NT 3.5 .gov sites are out there .... any other reasons not to do this? Maybe, but here's the real question - why in the hell would we want to do this? From list at satchell.net Mon Oct 20 14:52:13 2014 From: list at satchell.net (Stephen Satchell) Date: Mon, 20 Oct 2014 07:52:13 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <93034.1413814845@turing-police.cc.vt.edu> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> Message-ID: <5445219D.6070409@satchell.net> On 10/20/2014 07:20 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 20 Oct 2014 05:58:01 -0400, shawn wilson said: > >> Bad idea. I'm betting we'd find half of gov web sites down due to not being >> able to reboot and issues in old coldfusion and IIS and the like (and >> needing to fix static links and testing etc). > > You say that like it's a bad thing.... It's a dollar thing -- show me a substantial return on the investment and I'll back it all the way. Notice that nowhere in the litany do the terms "LAMP" or "Linux" show up. Adobe and Microsoft would *love* the increased revenue from updates that would have to be applied to all those old servers. And what about those sites that were made using Front Page? Talk about a nightmare. A costly one. "A billion here, a billion there, soon you are talking about real money." -- misattributed to the late Senator Everett Dirkson (1896-1969, R-Illinois 1951-69) From ag4ve.us at gmail.com Mon Oct 20 15:06:38 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 11:06:38 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <5445219D.6070409@satchell.net> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <5445219D.6070409@satchell.net> Message-ID: On Mon, Oct 20, 2014 at 10:52 AM, Stephen Satchell wrote: > On 10/20/2014 07:20 AM, Valdis.Kletnieks at vt.edu wrote: >> On Mon, 20 Oct 2014 05:58:01 -0400, shawn wilson said: >> >>> Bad idea. I'm betting we'd find half of gov web sites down due to not being >>> able to reboot and issues in old coldfusion and IIS and the like (and >>> needing to fix static links and testing etc). >> >> You say that like it's a bad thing.... > > It's a dollar thing -- show me a substantial return on the investment Indeed > > Adobe and Microsoft would *love* the increased revenue from updates that > would have to be applied to all those old servers. And what about those > sites that were made using Front Page? Talk about a nightmare. A > costly one. > Oh yeah, I totally forgot about old FrontPage. I was thinking Homesite or Dreamweaver, but idk FrontPage from ~10 years back would port very clean into anything modern. So, if anything there needed changing, you'd have to do a manual cleanup of that code. From Bryan at bryanfields.net Mon Oct 20 15:09:27 2014 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 20 Oct 2014 11:09:27 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <544525A7.5000509@bryanfields.net> On 10/19/14, 8:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? > > Would love to get any info about the history > of the decision to make it US-only. The USA funded the early internet and so it got to make it's own legacy rules. `murica :D -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Valdis.Kletnieks at vt.edu Mon Oct 20 15:44:37 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Oct 2014 11:44:37 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: Your message of "Mon, 20 Oct 2014 10:45:44 -0400." References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> Message-ID: <3374.1413819877@turing-police.cc.vt.edu> On Mon, 20 Oct 2014 10:45:44 -0400, shawn wilson said: > 3. I don't want to see the report on how many Allaire ColdFusion with > NT 3.5 .gov sites are out there > > .... any other reasons not to do this? Maybe, but here's the real > question - why in the hell would we want to do this? See your point 3. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From fred at cisco.com Mon Oct 20 16:50:28 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Mon, 20 Oct 2014 16:50:28 +0000 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> On Oct 19, 2014, at 5:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? > > Would love to get any info about the history > of the decision to make it US-only. > > Thanks! > > Matt The short version is that that names were a process. In the beginning, hosts simply had names. When DNS came into being, names were transformed from “some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came into being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names quickly fell into disuse. ccTLDs came later. I’ve been told that the reason God was able to create the earth in seven days was that He had no installed base. We do. The funny thing is that you’ll see a reflection of the gTLDs underneath the ccTLDs of a number of countries - .ac, .ed, and the like. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wbailey at satelliteintelligencegroup.com Mon Oct 20 17:01:52 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 20 Oct 2014 17:01:52 +0000 Subject: Why is .gov only for US government agencies? In-Reply-To: <544525A7.5000509@bryanfields.net> References: , <544525A7.5000509@bryanfields.net> Message-ID: <6w2332y0avb5so2vxrp4s45o.1413824504958@email.android.com> I wish marriages worked like that.. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Bryan Fields Date: 10/20/2014 8:13 AM (GMT-08:00) To: NANOG list Subject: Re: Why is .gov only for US government agencies? On 10/19/14, 8:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level gtlds be generically open to anyone > regardless of borders? > > Would love to get any info about the history > of the decision to make it US-only. The USA funded the early internet and so it got to make it's own legacy rules. `murica :D -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From jco at direwolf.com Mon Oct 20 17:07:13 2014 From: jco at direwolf.com (John Orthoefer) Date: Mon, 20 Oct 2014 13:07:13 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> Message-ID: > On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) wrote: > > […] and the older .arpa names quickly fell into disuse. People don’t use in-addr.arpa anymore? ;) johno From fred at cisco.com Mon Oct 20 17:14:22 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Mon, 20 Oct 2014 17:14:22 +0000 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> Message-ID: <48919DEA-275C-4ADE-AA15-F2F1A9FB0AC7@cisco.com> On Oct 20, 2014, at 10:07 AM, John Orthoefer wrote: > >> On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) wrote: >> >> […] and the older .arpa names quickly fell into disuse. > > > People don’t use in-addr.arpa anymore? ;) > > johno They do use that, of course. But for example they don’t go to IANA using a .arpa name. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dougb at dougbarton.us Mon Oct 20 17:18:13 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Oct 2014 10:18:13 -0700 Subject: GApps admin = rogered In-Reply-To: <54373A5D.7020703@cox.net> References: <1B8Z1p00e1cZc5601B8v4S> <54373A5D.7020703@cox.net> Message-ID: <544543D5.1080800@dougbarton.us> On 10/9/14 6:46 PM, Larry Sheldon wrote: > For me and any others here in the "F" row, a question about the use and > meaning and implication of the use of the word "rogered". "F" row indeed :) From asullivan at dyn.com Mon Oct 20 17:23:02 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Mon, 20 Oct 2014 13:23:02 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> Message-ID: <20141020172301.GO30980@dyn.com> On Mon, Oct 20, 2014 at 01:07:13PM -0400, John Orthoefer wrote: > People don’t use in-addr.arpa anymore? ;) Hadn't you noticed how bad the reverse mapping maintenance is? A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From humbertogaliza at gmail.com Mon Oct 20 18:31:44 2014 From: humbertogaliza at gmail.com (Humberto Galiza) Date: Mon, 20 Oct 2014 15:31:44 -0300 Subject: Softlayer (AS36351) network contact Message-ID: Can someone from softlayer/networklayer contact me off list please. thks, Humberto Galiza From sandy at tislabs.com Mon Oct 20 19:19:00 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Mon, 20 Oct 2014 15:19:00 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> Message-ID: By the time of RFC1591, March 1994, authored by Jon Postel, said: GOV - This domain was originally intended for any kind of government office or agency. More recently a decision was taken to register only agencies of the US Federal government in this domain. No reference as to who, when, or how. That same RFC says: In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166. It is extremely unlikely that any other TLDs will be created. Gotta love that last sentence, yes? --Sandy On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) wrote: > > On Oct 19, 2014, at 5:05 AM, Matthew Petach wrote: > >> Wondering if some of the long-time list members >> can shed some light on the question--why is the >> .gov top level domain only for use by US >> government agencies? Where do other world >> powers put their government agency domains? >> >> With the exception of the cctlds, shouldn't the >> top-level gtlds be generically open to anyone >> regardless of borders? >> >> Would love to get any info about the history >> of the decision to make it US-only. >> >> Thanks! >> >> Matt > > The short version is that that names were a process. In the beginning, hosts simply had names. When DNS came into being, names were transformed from “some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came into being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names quickly fell into disuse. > > ccTLDs came later. > > I’ve been told that the reason God was able to create the earth in seven days was that He had no installed base. We do. The funny thing is that you’ll see a reflection of the gTLDs underneath the ccTLDs of a number of countries - .ac, .ed, and the like. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alvarezp at alvarezp.ods.org Mon Oct 20 19:22:34 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 20 Oct 2014 12:22:34 -0700 Subject: large BCP38 compliance testing In-Reply-To: References: <43245.1412265241@turing-police.cc.vt.edu> Message-ID: <544560FA.8020902@alvarezp.ods.org> On 05/10/14 18:44, Jimmy Hess wrote: > On Thu, Oct 2, 2014 at 10:54 AM, wrote: >> The *real* problem isn't the testing. >> It's the assumption that you can actually *do* anything useful with this data. >> Name-n-shame probably won't get us far - and the way the US works, if there's a > > At least "name and shame" is something more useful than nothing done. Has it worked for the deaggregation offenders named by the CIDR report? From eric at ericheather.com Mon Oct 20 19:44:32 2014 From: eric at ericheather.com (Eric C. Miller) Date: Mon, 20 Oct 2014 19:44:32 +0000 Subject: Netgear Message-ID: Is there anyone from Netgear on this list? If you could contact me off-list, it was be appreciated. Thanks! Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From khelms at zcorum.com Mon Oct 20 19:50:02 2014 From: khelms at zcorum.com (Scott Helms) Date: Mon, 20 Oct 2014 15:50:02 -0400 Subject: Netgear In-Reply-To: References: Message-ID: Eric, You may want to be a little more specific. I know from personal experience that the divisions inside of Netgear (corporate/enterprise, direct to consumer, and service provider) don't work together nor have common infrastructure in many cases. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Mon, Oct 20, 2014 at 3:44 PM, Eric C. Miller wrote: > Is there anyone from Netgear on this list? If you could contact me > off-list, it was be appreciated. > > Thanks! > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > From tony at wicks.co.nz Mon Oct 20 20:16:16 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 21 Oct 2014 09:16:16 +1300 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: <007f01cfeca2$b4c6fab0$1e54f010$@wicks.co.nz> >Hey all, > >Just wondering what/if people are using any shaping hardware/appliances >these days, and if so, what. > >I have a client which has thousands of customers on Satellite and needs to >restrict some users who are doing a lot. > >So I wanted to see what the current popular equipment out there is. > I get pretty good results out of Fortinet Fortigate firewalls (100D/800C/1500D). I use them for both web filtering and P2P rate control. They also do WAN optimisation and some caching but I have not used that. They scale up to 20+gig (FG3700D). When looking at the scaling you need to use the IPS throughput rating if you are turning on DPI for P2P control. Cost wise they are pretty good against other DPI boxes. From skeeve+nanog at eintellegonetworks.com Mon Oct 20 21:34:30 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Tue, 21 Oct 2014 08:34:30 +1100 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: What I'd really love is a vAppliance. Some of these hardware solutions are VERY expensive for offering only an average solution. I'd also rather not rely on their hardware, but servers with VMware (or whatever) that we can design our own redundancy. Does anyone know if Allot does a Virtual Appliance? I've also heard that pfSense is an interesting option... That could easily be virtualised I would assume. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On 20 October 2014 22:31, Nurul Islam Roman wrote: > Used following two product to shape traffic on packet level (L3). Had no > issue with several thousand customer. > > Allot > http://www.allot.com/netenforcer.html > > ET > http://www.etinc.com/ > > Found "Allot" is very popular for satellite based Internet specially in > south pacific island countries. > > -R > > > On 20/10/14 2:55 PM, "Skeeve Stevens" > wrote: > > >Hey all, > > > >Just wondering what/if people are using any shaping hardware/appliances > >these days, and if so, what. > > > >I have a client which has thousands of customers on Satellite and needs to > >restrict some users who are doing a lot. > > > >So I wanted to see what the current popular equipment out there is. > > > >...Skeeve > > > >*Skeeve Stevens - *eintellego Networks Pty Ltd > >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > > >facebook.com/eintellegonetworks ; > >linkedin.com/in/skeeve > > > >experts360: https://expert360.com/profile/d54a9 > > > >twitter.com/theispguy ; blog: www.theispguy.com > > > > > >The Experts Who The Experts Call > >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > From rafael at gav.ufsc.br Mon Oct 20 21:45:40 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 20 Oct 2014 16:45:40 -0500 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Yes, pfSense can be virtualized. I did it once with VMWare to create a site2site tunnel, although I used Workstation 10 on Windows7 rather than the bare metal ESXi, but I wouldn't expect any changes. On Mon, Oct 20, 2014 at 4:34 PM, Skeeve Stevens < skeeve+nanog at eintellegonetworks.com> wrote: > What I'd really love is a vAppliance. Some of these hardware solutions are > VERY expensive for offering only an average solution. I'd also rather not > rely on their hardware, but servers with VMware (or whatever) that we can > design our own redundancy. > > Does anyone know if Allot does a Virtual Appliance? > > I've also heard that pfSense is an interesting option... That could easily > be virtualised I would assume. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > On 20 October 2014 22:31, Nurul Islam Roman wrote: > > > Used following two product to shape traffic on packet level (L3). Had no > > issue with several thousand customer. > > > > Allot > > http://www.allot.com/netenforcer.html > > > > ET > > http://www.etinc.com/ > > > > Found "Allot" is very popular for satellite based Internet specially in > > south pacific island countries. > > > > -R > > > > > > On 20/10/14 2:55 PM, "Skeeve Stevens" > > wrote: > > > > >Hey all, > > > > > >Just wondering what/if people are using any shaping hardware/appliances > > >these days, and if so, what. > > > > > >I have a client which has thousands of customers on Satellite and needs > to > > >restrict some users who are doing a lot. > > > > > >So I wanted to see what the current popular equipment out there is. > > > > > >...Skeeve > > > > > >*Skeeve Stevens - *eintellego Networks Pty Ltd > > >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > > > > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > > > > >facebook.com/eintellegonetworks ; > > >linkedin.com/in/skeeve > > > > > >experts360: https://expert360.com/profile/d54a9 > > > > > >twitter.com/theispguy ; blog: www.theispguy.com > > > > > > > > >The Experts Who The Experts Call > > >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > > From bmanning at isi.edu Mon Oct 20 22:09:42 2014 From: bmanning at isi.edu (manning bill) Date: Mon, 20 Oct 2014 15:09:42 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> Message-ID: <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> FNC “reserved” .gov and .mil for the US. And Postel was right… there was/is near zero reason to technically extend/expand the number of TLDs. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 20October2014Monday, at 12:19, Sandra Murphy wrote: > By the time of RFC1591, March 1994, authored by Jon Postel, said: > > GOV - This domain was originally intended for any kind of government > office or agency. More recently a decision was taken to > register only agencies of the US Federal government in this > domain. > > No reference as to who, when, or how. > > That same RFC says: > > In the Domain Name System (DNS) naming of computers there is a > hierarchy of names. The root of system is unnamed. There are a set > of what are called "top-level domain names" (TLDs). These are the > generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two > letter country codes from ISO-3166. It is extremely unlikely that > any other TLDs will be created. > > Gotta love that last sentence, yes? > > --Sandy > > On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) wrote: > >> >> On Oct 19, 2014, at 5:05 AM, Matthew Petach wrote: >> >>> Wondering if some of the long-time list members >>> can shed some light on the question--why is the >>> .gov top level domain only for use by US >>> government agencies? Where do other world >>> powers put their government agency domains? >>> >>> With the exception of the cctlds, shouldn't the >>> top-level gtlds be generically open to anyone >>> regardless of borders? >>> >>> Would love to get any info about the history >>> of the decision to make it US-only. >>> >>> Thanks! >>> >>> Matt >> >> The short version is that that names were a process. In the beginning, hosts simply had names. When DNS came into being, names were transformed from “some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came into being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names quickly fell into disuse. >> >> ccTLDs came later. >> >> I’ve been told that the reason God was able to create the earth in seven days was that He had no installed base. We do. The funny thing is that you’ll see a reflection of the gTLDs underneath the ccTLDs of a number of countries - .ac, .ed, and the like. > From dougb at dougbarton.us Mon Oct 20 22:26:26 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Oct 2014 15:26:26 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: Message-ID: <54458C12.7030003@dougbarton.us> On 10/19/14 5:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? ... I think these questions have been adequately answered. In regards to the question of "Ok, so what do we do about it?" a simple plan was floated oh, about a decade ago: 1. Create edu.us, gov.us, and mil.us 2. Lock out all new registrations in EDU, GOV, and MIL 3. Set a target date for the removal of those TLDs for 10 years in the future Obviously there are various implementation details for effecting the move, but application-layer stuff will be as obvious to most readers as it is off-topic for this list. Regarding the time period in #3, decommissioning a TLD is harder than you might think, and we have plenty of extant examples of others that have taken longer, and/or haven't finished yet *cough*su*cough*. Obviously no serious consideration was given to that plan 10 years ago, or we wouldn't still be having the conversation today. :) Meanwhile what most perceive as the USG's privileged position in the operation of the root zone is still being reinforced by those TLDs, in spite of the current IANA stewardship transition talks. Doug From larrysheldon at cox.net Mon Oct 20 22:46:09 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 20 Oct 2014 17:46:09 -0500 Subject: Why is .gov only for US government agencies? In-Reply-To: <5aBQ1p01A1cZc5601aBSzF> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <5aBQ1p01A1cZc5601aBSzF> Message-ID: <544590B1.5080700@cox.net> On 10/20/2014 17:09, manning bill wrote: > FNC “reserved” .gov and .mil for the US. > > And Postel was right… there was/is near zero reason to technically > extend/expand the number of TLDs. It appears to this outsider that Postel and others never understood at all that the sole purpose and destiny of what they were inventing was Marketing, with secondary importance in social networking and politics. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From ag4ve.us at gmail.com Mon Oct 20 22:54:12 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 18:54:12 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <3374.1413819877@turing-police.cc.vt.edu> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> Message-ID: On Mon, Oct 20, 2014 at 11:44 AM, wrote: > On Mon, 20 Oct 2014 10:45:44 -0400, shawn wilson said: > >> 3. I don't want to see the report on how many Allaire ColdFusion with >> NT 3.5 .gov sites are out there >> >> .... any other reasons not to do this? Maybe, but here's the real >> question - why in the hell would we want to do this? > > See your point 3. I think you're assuming that people go back and fix stuff when they do massive changes that are out of scope - they don't. First they aren't being paid to do so, gov contractors always run over budget and work is never delivered on time so why would they want to make it worse, etc. No, if a massive domain move started, stuff would be fixed enough to make it work with a new domain, and stuff would stay at and possibly worse than the current state of "working". I can handle stuff staying at the current state as long as China/Russia doesn't use it to get more of a foothold into our infrastructure, but making this stuff worse might be a really bad thing. Just something to consider - lets say web stuff is ok, email ports, old SOAP (and whatever was/is used on mainframes) stuff doesn't break. I'm betting something accesses relay-4.building-10.not-yet-offline.missile-defense-system.mil someone fails to point to building-10's dns in a dns migration which may be a cooling system that gets changed by some computer and shit hits the fan because we wanted to normalize our gov tld with the rest of the world. No, I think I'll pass on finding out what breaks here. Again - give me a real reason we should do this. And if not, if it ain't broke, don't fix it. PS - MDS is only 10 years old so any part of that still online is likely to have audits (and any installs would be in east-EU and hopefully on classified internet - one hopes - so who knows). It was just an example I pulled. It's more possible that some Blackberry system can't get updated after we stop holding them up and we budget for this and gov email goes down :) Just saying I don't want to find out what gets left behind and breaks here. From asr at latency.net Mon Oct 20 23:05:06 2014 From: asr at latency.net (Adam Rothschild) Date: Mon, 20 Oct 2014 19:05:06 -0400 Subject: Tinet on strike? Message-ID: Provided without commentary, in case this impacts some operations: https://www.facebook.com/Tinetworkers/ https://twitter.com/TinetStrike/with_replies From ag4ve.us at gmail.com Mon Oct 20 23:07:32 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 19:07:32 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <54458C12.7030003@dougbarton.us> References: <54458C12.7030003@dougbarton.us> Message-ID: On Mon, Oct 20, 2014 at 6:26 PM, Doug Barton wrote: > 3. Set a target date for the removal of those TLDs for 10 years in the > future > Because this worked for IPv6? > Obviously there are various implementation details for effecting the move, > but application-layer stuff will be as obvious to most readers as it is > off-topic for this list. > In this case, it's all about the "application-layer stuff" - that'd be the stuff to fail hard - mainframe IP gateways, control systems, Lotus, Domino, etc. BIND is fine. Even most of the PHP apps would (should, maybe) be fine. But that's not runs most of the gov. > Regarding the time period in #3, decommissioning a TLD is harder than you > might think, and we have plenty of extant examples of others that have taken > longer, and/or haven't finished yet *cough*su*cough*. > Do we really have any prior examples that are even .1 the size of the usgov public system? Again, I'm not just referring to BIND and Windows DNS (and probably some Netware 4 etc stuff) - this would be web, soap parsers, email systems, vpn, and all of their clients (public, contractor, and gov). Anything close to what y'all are talking about? From marcus.sachs at verizon.com Mon Oct 20 23:20:19 2014 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Mon, 20 Oct 2014 19:20:19 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <54458C12.7030003@dougbarton.us> References: <54458C12.7030003@dougbarton.us> Message-ID: I remember asking this same question when I first started managing DNS records in the early 1990s. Being young and unencumbered by "it's always been done this way" thinking I believed that it would only be a few years of transition and .mil/.gov would be pushed to the history books. Now I'm older and crankier and a grandfather. Along with asking the "who cares?" question the image of Grandpa Simpson also comes to mind: "GET OFF MY LAWN!" Marc -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Doug Barton Sent: Monday, October 20, 2014 6:26 PM To: nanog at nanog.org Subject: Re: Why is .gov only for US government agencies? On 10/19/14 5:05 AM, Matthew Petach wrote: > Wondering if some of the long-time list members can shed some light on > the question--why is the .gov top level domain only for use by US > government agencies? Where do other world powers put their government > agency domains? ... I think these questions have been adequately answered. In regards to the question of "Ok, so what do we do about it?" a simple plan was floated oh, about a decade ago: 1. Create edu.us, gov.us, and mil.us 2. Lock out all new registrations in EDU, GOV, and MIL 3. Set a target date for the removal of those TLDs for 10 years in the future Obviously there are various implementation details for effecting the move, but application-layer stuff will be as obvious to most readers as it is off-topic for this list. Regarding the time period in #3, decommissioning a TLD is harder than you might think, and we have plenty of extant examples of others that have taken longer, and/or haven't finished yet *cough*su*cough*. Obviously no serious consideration was given to that plan 10 years ago, or we wouldn't still be having the conversation today. :) Meanwhile what most perceive as the USG's privileged position in the operation of the root zone is still being reinforced by those TLDs, in spite of the current IANA stewardship transition talks. Doug From marka at isc.org Tue Oct 21 00:05:25 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Oct 2014 11:05:25 +1100 Subject: Why is .gov only for US government agencies? In-Reply-To: Your message of "Mon, 20 Oct 2014 19:07:32 -0400." References: <54458C12.7030003@dougbarton.us> Message-ID: <20141021000525.50E98221D692@rock.dv.isc.org> In message , shawn wilson writes: > On Mon, Oct 20, 2014 at 6:26 PM, Doug Barton wrote: > > > 3. Set a target date for the removal of those TLDs for 10 years in the > > future > > Because this worked for IPv6? Well there wasn't a target date set for the change to IPv6 and it is starting to happen pretty fast now. These are nameserver by IP type (IPv4 then IPv6). For Alexa top 1000, Alexa AU zones, Alexa bottom 1000 of top 1M, Alexa GOV zones and TLD/Root zone. % foreach f ( tld-report/reports/*2014-10-20* ) foreach? echo $f foreach? awk '$2 !~ /:/ { print $2}' $f | sort -u | wc foreach? awk '$2 ~ /:/ { print $2}' $f | sort -u | wc foreach? end tld-report/reports/alexa.2014-10-20T00:00:00Z 2178 2178 33180 513 513 11131 tld-report/reports/au.2014-10-20T00:00:12Z 6343 6343 97529 726 726 16441 tld-report/reports/bottom.2014-10-20T00:00:12Z 1788 1788 26945 416 416 9660 tld-report/reports/gov.2014-10-20T00:00:12Z 1263 1263 18821 301 301 6765 tld-report/reports/tld.2014-10-20T00:00:00Z 1602 1602 23035 1065 1065 20276 % Or over all the servers % awk '$2 !~ /:/ { print $2}' tld-report/reports/*2014-10-20* | sort -u | wc 11805 11805 178630 % awk '$2 ~ /:/ { print $2}' tld-report/reports/*2014-10-20* | sort -u | wc 2554 2554 53979 % Now who says IPv6 hasn't taken off? Setting target dates helps. Having a administator willing to pull the plug on the set date helps even more. .ARPA was cleared of hosts because there was a date set and the last entries were removed even if the operators of the hosts weren't ready. There was never any intention to remove in-addr.arpa. > > Obviously there are various implementation details for effecting the move, > > but application-layer stuff will be as obvious to most readers as it is > > off-topic for this list. > > In this case, it's all about the "application-layer stuff" - that'd be > the stuff to fail hard - mainframe IP gateways, control systems, > Lotus, Domino, etc. BIND is fine. Even most of the PHP apps would > (should, maybe) be fine. But that's not runs most of the gov. > > > Regarding the time period in #3, decommissioning a TLD is harder than you > > might think, and we have plenty of extant examples of others that have take > n > > longer, and/or haven't finished yet *cough*su*cough*. > > > > Do we really have any prior examples that are even .1 the size of the > usgov public system? Again, I'm not just referring to BIND and Windows > DNS (and probably some Netware 4 etc stuff) - this would be web, soap > parsers, email systems, vpn, and all of their clients (public, > contractor, and gov). Anything close to what y'all are talking about? Government departments get re-named all the time. Many departments have already gone through name changes since coming onto the net. This would just be another one. Size really isn't a issue, there are more than enough staff to do this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tomas.lynch at gmail.com Tue Oct 21 00:24:19 2014 From: tomas.lynch at gmail.com (Tomas Lynch) Date: Mon, 20 Oct 2014 20:24:19 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <20141021000525.50E98221D692@rock.dv.isc.org> References: <54458C12.7030003@dougbarton.us> <20141021000525.50E98221D692@rock.dv.isc.org> Message-ID: Spanish speaking countries .gob.$2lettercodecountry. No problem so far. On Mon, Oct 20, 2014 at 8:05 PM, Mark Andrews wrote: > > In message > , shawn wilson writes: >> On Mon, Oct 20, 2014 at 6:26 PM, Doug Barton wrote: >> >> > 3. Set a target date for the removal of those TLDs for 10 years in the >> > future >> >> Because this worked for IPv6? > > Well there wasn't a target date set for the change to IPv6 and it > is starting to happen pretty fast now. > > These are nameserver by IP type (IPv4 then IPv6). For Alexa top > 1000, Alexa AU zones, Alexa bottom 1000 of top 1M, Alexa GOV zones > and TLD/Root zone. > > % foreach f ( tld-report/reports/*2014-10-20* ) > foreach? echo $f > foreach? awk '$2 !~ /:/ { print $2}' $f | sort -u | wc > foreach? awk '$2 ~ /:/ { print $2}' $f | sort -u | wc > foreach? end > tld-report/reports/alexa.2014-10-20T00:00:00Z > 2178 2178 33180 > 513 513 11131 > tld-report/reports/au.2014-10-20T00:00:12Z > 6343 6343 97529 > 726 726 16441 > tld-report/reports/bottom.2014-10-20T00:00:12Z > 1788 1788 26945 > 416 416 9660 > tld-report/reports/gov.2014-10-20T00:00:12Z > 1263 1263 18821 > 301 301 6765 > tld-report/reports/tld.2014-10-20T00:00:00Z > 1602 1602 23035 > 1065 1065 20276 > % > > Or over all the servers > > % awk '$2 !~ /:/ { print $2}' tld-report/reports/*2014-10-20* | sort -u | wc > 11805 11805 178630 > % awk '$2 ~ /:/ { print $2}' tld-report/reports/*2014-10-20* | sort -u | wc > 2554 2554 53979 > % > > Now who says IPv6 hasn't taken off? > > Setting target dates helps. Having a administator willing to pull > the plug on the set date helps even more. .ARPA was cleared of > hosts because there was a date set and the last entries were removed > even if the operators of the hosts weren't ready. There was never > any intention to remove in-addr.arpa. > >> > Obviously there are various implementation details for effecting the move, >> > but application-layer stuff will be as obvious to most readers as it is >> > off-topic for this list. >> >> In this case, it's all about the "application-layer stuff" - that'd be >> the stuff to fail hard - mainframe IP gateways, control systems, >> Lotus, Domino, etc. BIND is fine. Even most of the PHP apps would >> (should, maybe) be fine. But that's not runs most of the gov. >> >> > Regarding the time period in #3, decommissioning a TLD is harder than you >> > might think, and we have plenty of extant examples of others that have take >> n >> > longer, and/or haven't finished yet *cough*su*cough*. >> > >> >> Do we really have any prior examples that are even .1 the size of the >> usgov public system? Again, I'm not just referring to BIND and Windows >> DNS (and probably some Netware 4 etc stuff) - this would be web, soap >> parsers, email systems, vpn, and all of their clients (public, >> contractor, and gov). Anything close to what y'all are talking about? > > Government departments get re-named all the time. Many departments > have already gone through name changes since coming onto the net. > This would just be another one. > > Size really isn't a issue, there are more than enough staff to do this. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From israel.lugo at lugosys.com Tue Oct 21 00:48:35 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Tue, 21 Oct 2014 01:48:35 +0100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch Message-ID: <5445AD63.7090400@lugosys.com> Hi, Not intending to start a flame war here. I have been referred to the website below, and believe they certainly raise some valid concerns. http://www.debianfork.org/ If you have the time, please take a moment to read over the text, and follow a few links. I am quoting the first few paragraphs as a summary: > We are Veteran Unix Admins and we are concerned about what is > happening to Debian GNU/Linux to the point of considering a > fork of the project. > > Some of us are upstream developers, some professional > sysadmins: we are all concerned peers interacting with Debian > and derivatives on a daily basis. > > We don't want to be forced to use systemd in substitution to > the traditional UNIX sysvinit init, because systemd betrays > the UNIX philosophy. > > We contemplate adopting more recent alternatives to sysvinit, > but not those undermining the basic design principles of "do > one thing and do it well" with a complex collection of dozens > of tightly coupled binaries and opaque logs. I understand discussion on this matter has been quite polarized in some circles. As stated, it's not my intention to start an argument on whether A is better than B, nor do I believe that to be the site's purpose. Rather, I would like to divulge and hopefully incite some productive discussion. Regards, Israel G. Lugo From woody at pch.net Tue Oct 21 01:10:48 2014 From: woody at pch.net (Bill Woodcock) Date: Tue, 21 Oct 2014 09:10:48 +0800 Subject: Why is .gov only for US government agencies? In-Reply-To: <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> Message-ID: <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> On Oct 21, 2014, at 6:09 AM, manning bill wrote: > there was/is near zero reason to technically extend/expand the number of TLDs. Equally, no reason not to. > On 20October2014Monday, at 12:19, Sandra Murphy wrote: > >> By the time of RFC1591, March 1994, authored by Jon Postel, said: >> >> GOV - This domain was originally intended for any kind of government >> office or agency. More recently a decision was taken to >> register only agencies of the US Federal government in this >> domain. >> >> No reference as to who, when, or how. Passive voice considered harmful. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cb.list6 at gmail.com Tue Oct 21 01:15:52 2014 From: cb.list6 at gmail.com (Ca By) Date: Mon, 20 Oct 2014 18:15:52 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: On Monday, October 20, 2014, Israel G. Lugo wrote: > Hi, > > Not intending to start a flame war here. I have been referred to the > website below, and believe they certainly raise some valid concerns. > > http://www.debianfork.org/ > > If you have the time, please take a moment to read over the text, and > follow a few links. I am quoting the first few paragraphs as a summary: > > > We are Veteran Unix Admins and we are concerned about what is > > happening to Debian GNU/Linux to the point of considering a > > fork of the project. > > > > Some of us are upstream developers, some professional > > sysadmins: we are all concerned peers interacting with Debian > > and derivatives on a daily basis. > > > > We don't want to be forced to use systemd in substitution to > > the traditional UNIX sysvinit init, because systemd betrays > > the UNIX philosophy. > > > > We contemplate adopting more recent alternatives to sysvinit, > > but not those undermining the basic design principles of "do > > one thing and do it well" with a complex collection of dozens > > of tightly coupled binaries and opaque logs. > > I understand discussion on this matter has been quite polarized in some > circles. As stated, it's not my intention to start an argument on > whether A is better than B, nor do I believe that to be the site's > purpose. Rather, I would like to divulge and hopefully incite some > productive discussion. > > Regards, > Israel G. Lugo > A diversity of implementations does a good ecosystem make. CB From jared at puck.nether.net Tue Oct 21 01:23:11 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 20 Oct 2014 18:23:11 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: Breaking tons of things is an interesting opinion of "why not". Jared Mauch > On Oct 20, 2014, at 6:10 PM, Bill Woodcock wrote: > > Equally, no reason not to. From woody at pch.net Tue Oct 21 01:30:31 2014 From: woody at pch.net (Bill Woodcock) Date: Tue, 21 Oct 2014 09:30:31 +0800 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: On Oct 21, 2014, at 9:23 AM, Jared Mauch wrote: > Breaking tons of things is an interesting opinion of "why not”. Eh. Off the top of my head, I see two categories of breakage: 1) things that hard-code a list of “real” TLDs, and break when their expectations aren’t met, and 2) things that went ahead and trumped up their own non-canonical TLDs for their own purposes. Neither of those seem like practices worth defending, to me. Not worth going out of one’s way to break, either, but… And in the latter case, like “alternate roots,” that’s not an argument against creating more TLDs… They’ve already been created. It’s an argument against doing so in an uncoordinated manner, which is the source of the breakage. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ag4ve.us at gmail.com Tue Oct 21 02:09:11 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 20 Oct 2014 22:09:11 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: On Oct 20, 2014 9:33 PM, "Bill Woodcock" wrote: > > > On Oct 21, 2014, at 9:23 AM, Jared Mauch wrote: > > > Breaking tons of things is an interesting opinion of "why not”. > > Eh. Off the top of my head, I see two categories of breakage: > > 1) things that hard-code a list of “real” TLDs, and break when their expectations aren’t met, and > > 2) things that went ahead and trumped up their own non-canonical TLDs for their own purposes. > > Neither of those seem like practices worth defending, to me. Not worth going out of one’s way to break, either, but… > I'm not defending any practice. Let's just say everything else goes smooth. How many fed employees are there and what's their average salary? Let's assume it takes them 5 minutes to change their email sig. How much would that cost? There's probably also a legal issue 1here. You can't make it so that someone can't communicate with their elected official. No term limits in the House so you'd start this and 50 years later, you'd be able to complete the project (due to the last congressman being replaced). From drc at virtualized.org Tue Oct 21 02:13:32 2014 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Oct 2014 19:13:32 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: <7E988718-E93F-43AE-B9DF-4DFA63473B39@virtualized.org> Jared, On Oct 20, 2014, at 6:23 PM, Jared Mauch wrote: > Breaking tons of things is an interesting opinion of "why not". Beyond challenges caused by https://www.icann.org/resources/pages/name-collision-2013-12-06-en, is there something new TLDs is breaking? (Serious question) Thanks, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Tue Oct 21 02:20:03 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Oct 2014 22:20:03 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: Your message of "Mon, 20 Oct 2014 22:09:11 -0400." References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: <17863.1413858003@turing-police.cc.vt.edu> On Mon, 20 Oct 2014 22:09:11 -0400, shawn wilson said: > There's probably also a legal issue 1here. You can't make it so that > someone can't communicate with their elected official. You might want to actually surf over to house.gov and start looking at how many totally broken pages are there. Enough so that "you can't make it so that someone can't communicate" doesn't hold water, 'cause it happens all the time... And if your email admin can't figure out how to alias *@house.gov to *@house.gov.us, you got bigger problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From marka at isc.org Tue Oct 21 02:23:26 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Oct 2014 13:23:26 +1100 Subject: Why is .gov only for US government agencies? In-Reply-To: Your message of "Mon, 20 Oct 2014 22:09:11 -0400." References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: <20141021022326.366A92226700@rock.dv.isc.org> In message , shawn wilson writes: > On Oct 20, 2014 9:33 PM, "Bill Woodcock" wrote: > > > > > > On Oct 21, 2014, at 9:23 AM, Jared Mauch wrote: > > > > > Breaking tons of things is an interesting opinion of "why not”. > > > > Eh. Off the top of my head, I see two categories of breakage: > > > > 1) things that hard-code a list of “real” TLDs, and break when their > > expectations aren’t met, and > > > > 2) things that went ahead and trumped up their own non-canonical TLDs > > for their own purposes. > > > > Neither of those seem like practices worth defending, to me. Not worth > > going out of one’s way to break, either, but… > > > > I'm not defending any practice. Let's just say everything else goes > smooth. > How many fed employees are there and what's their average salary? Let's > assume it takes them 5 minutes to change their email sig. How much would > that cost? Over a 10 year transition period, $0. They will almost certainly make lots of other changes in that 10 year period. Change building, change title, change phone number ..... The list goes on and on. > There's probably also a legal issue 1here. You can't make it so that > someone can't communicate with their elected official. No term limits in > the House so you'd start this and 50 years later, you'd be able to > complete the project (due to the last congressman being replaced). There is postal address, phone number, office address, email address. All of these addresses change over time or were you under some strange illusion that these were immutable? Mark -- 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 Tue Oct 21 02:34:22 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 20 Oct 2014 19:34:22 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> Message-ID: <5445C62E.6070700@nic-naa.net> at ietf-9 jon and i discussed the problem solved (scaling of the zone editor function as the price of network interfaces dropped by orders of magnitude) by reliance upon iso3166-1, and the problems created by reliance upon iso3166-1. the economic success of .cat (unique among the icann 1st and 2nd round gtld projects) and the orders of magnitude growth of catalan (as measured by google) as the detected or announced language of network accessible content are facts. [note, as cto of the .cat project i'd no way of knowing either outcome would arise.] i remain of the view that language and culture, and fate independence from the vgrs business model are sufficient to expand on the 1591 set of namespaces. -e On 10/20/14 3:09 PM, manning bill wrote: > FNC “reserved” .gov and .mil for the US. > > And Postel was right… there was/is near zero reason to technically extend/expand the number of TLDs. > > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > On 20October2014Monday, at 12:19, Sandra Murphy wrote: > >> By the time of RFC1591, March 1994, authored by Jon Postel, said: >> >> GOV - This domain was originally intended for any kind of government >> office or agency. More recently a decision was taken to >> register only agencies of the US Federal government in this >> domain. >> >> No reference as to who, when, or how. >> >> That same RFC says: >> >> In the Domain Name System (DNS) naming of computers there is a >> hierarchy of names. The root of system is unnamed. There are a set >> of what are called "top-level domain names" (TLDs). These are the >> generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two >> letter country codes from ISO-3166. It is extremely unlikely that >> any other TLDs will be created. >> >> Gotta love that last sentence, yes? >> >> --Sandy >> >> On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) wrote: >> >>> On Oct 19, 2014, at 5:05 AM, Matthew Petach wrote: >>> >>>> Wondering if some of the long-time list members >>>> can shed some light on the question--why is the >>>> .gov top level domain only for use by US >>>> government agencies? Where do other world >>>> powers put their government agency domains? >>>> >>>> With the exception of the cctlds, shouldn't the >>>> top-level gtlds be generically open to anyone >>>> regardless of borders? >>>> >>>> Would love to get any info about the history >>>> of the decision to make it US-only. >>>> >>>> Thanks! >>>> >>>> Matt >>> The short version is that that names were a process. In the beginning, hosts simply had names. When DNS came into being, names were transformed from “some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came into being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names quickly fell into disuse. >>> >>> ccTLDs came later. >>> >>> I’ve been told that the reason God was able to create the earth in seven days was that He had no installed base. We do. The funny thing is that you’ll see a reflection of the gTLDs underneath the ccTLDs of a number of countries - .ac, .ed, and the like. > > > From nderitualex at gmail.com Tue Oct 21 02:36:34 2014 From: nderitualex at gmail.com (Alex Nderitu) Date: Tue, 21 Oct 2014 05:36:34 +0300 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Not sure if Allot has GA on the virtual appliances but they did a demo earlier this month http://www.allot.com/index.aspx?id=3797&itemID=158923 On 21 Oct 2014 00:37, "Skeeve Stevens" wrote: What I'd really love is a vAppliance. Some of these hardware solutions are VERY expensive for offering only an average solution. I'd also rather not rely on their hardware, but servers with VMware (or whatever) that we can design our own redundancy. Does anyone know if Allot does a Virtual Appliance? I've also heard that pfSense is an interesting option... That could easily be virtualised I would assume. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On 20 October 2014 22:31, Nurul Islam Roman wrote: > Used following two product to shape traffic on packet level (L3). Had no > issue with several thousand customer. > > Allot > http://www.allot.com/netenforcer.html > > ET > http://www.etinc.com/ > > Found "Allot" is very popular for satellite based Internet specially in > south pacific island countries. > > -R > > > On 20/10/14 2:55 PM, "Skeeve Stevens" > wrote: > > >Hey all, > > > >Just wondering what/if people are using any shaping hardware/appliances > >these days, and if so, what. > > > >I have a client which has thousands of customers on Satellite and needs to > >restrict some users who are doing a lot. > > > >So I wanted to see what the current popular equipment out there is. > > > >...Skeeve > > > >*Skeeve Stevens - *eintellego Networks Pty Ltd > >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > > >facebook.com/eintellegonetworks ; > >linkedin.com/in/skeeve > > > >experts360: https://expert360.com/profile/d54a9 > > > >twitter.com/theispguy ; blog: www.theispguy.com > > > > > >The Experts Who The Experts Call > >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > From brunner at nic-naa.net Tue Oct 21 02:47:15 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 20 Oct 2014 19:47:15 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <54458C12.7030003@dougbarton.us> References: <54458C12.7030003@dougbarton.us> Message-ID: <5445C933.4060200@nic-naa.net> having written the technical portion of winning proposal to ntia for the .us zone, i differ. as i recall, having done the research, in the year prior to the ntia's tender some six people held some 40% of the major metro area subordinate namespaces. to my chagrin, relieved by a notice of termination days before my stock in the company vested, the winner adopted a "orange-black" model, deprecating the namespace's existing hierarchical registration model for a flat registration model. the registration process model for .us is dissimilar to the registration process models of .edu, .mil and .gov, as are the contractors to the government. -e On 10/20/14 3:26 PM, Doug Barton wrote: > > Obviously no serious consideration was given to that plan 10 years > ago, or we wouldn't still be having the conversation today. From listas at esds.com.br Tue Oct 21 03:49:52 2014 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 21 Oct 2014 01:49:52 -0200 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Em segunda-feira, 20 de outubro de 2014, Rafael Possamai escreveu: > Yes, pfSense can be virtualized. I did it once with VMWare to create a > site2site tunnel, although I used Workstation 10 on Windows7 rather than > the bare metal ESXi, but I wouldn't expect any changes. > > What you think about BSDRP? It's another FreeBSD with ipfw and dummynet, very ease to use for shaping. -- Eduardo Schoedler -- Eduardo Schoedler From dougb at dougbarton.us Tue Oct 21 03:54:04 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Oct 2014 20:54:04 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <54458C12.7030003@dougbarton.us> Message-ID: <5445D8DC.8050806@dougbarton.us> On 10/20/14 4:07 PM, shawn wilson wrote: > On Mon, Oct 20, 2014 at 6:26 PM, Doug Barton wrote: > >> 3. Set a target date for the removal of those TLDs for 10 years in the >> future >> > > Because this worked for IPv6? Actually it worked really well for IPv6 in USG-space. It also mostly worked for DNSSEC. Orgs that didn't make the deadline got spanked, and remediated. Of course DNSSEC in GOV has been a mixed bag, but to be fair, that's true of all the early adopters. >> Obviously there are various implementation details for effecting the move, >> but application-layer stuff will be as obvious to most readers as it is >> off-topic for this list. >> > > In this case, it's all about the "application-layer stuff" - that'd be > the stuff to fail hard - mainframe IP gateways, control systems, > Lotus, Domino, etc. BIND is fine. Even most of the PHP apps would > (should, maybe) be fine. But that's not runs most of the gov. No argument, which is why the long tail. A non-trivial amount of that stuff will go away by attrition over a decade, and the rest will just have to be moved carefully. >> Regarding the time period in #3, decommissioning a TLD is harder than you >> might think, and we have plenty of extant examples of others that have taken >> longer, and/or haven't finished yet *cough*su*cough*. >> > > Do we really have any prior examples that are even .1 the size of the > usgov public system? Again, I'm not just referring to BIND and Windows > DNS (and probably some Netware 4 etc stuff) - this would be web, soap > parsers, email systems, vpn, and all of their clients (public, > contractor, and gov). Anything close to what y'all are talking about? Actually I think I could make a very convincing argument that GOV would not be the most challenging problem of the 3 I mentioned, but I won't. :) The question here is not, "Is it easy?" The questions are, "Is it the right thing to do?" and "Will it get easier to do tomorrow than it would have been to do today?" I can tell you beyond a shadow of a doubt that it would have been easier to do a decade ago, and 10 years from now it will be harder still. Doug From dougb at dougbarton.us Tue Oct 21 03:54:42 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Oct 2014 20:54:42 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: <5445D902.9060900@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/20/14 6:30 PM, Bill Woodcock wrote: | | On Oct 21, 2014, at 9:23 AM, Jared Mauch | wrote: | |> Breaking tons of things is an interesting opinion of "why not”. | | Eh. Off the top of my head, I see two categories of breakage: | | 1) things that hard-code a list of “real” TLDs, and break when | their expectations aren’t met, and | | 2) things that went ahead and trumped up their own non-canonical | TLDs for their own purposes. | | Neither of those seem like practices worth defending, to me. Not | worth going out of one’s way to break, either, but… Agree 100% -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJURdkCAAoJEFzGhvEaGryESOoIALGQRCkydGcbtt8ETfkaSwrp bigHmXH/ljEZVX2DpA2IthtXME7OEOMFlVsm9HAbWuCZaRAbVHlJPWVEaSuunrj7 jeQxir22mO3RX4Yil577u9k+/woa+5m9ymyuLHnSJHNSL7Lnqw4BKjUgPPEm66+r 9D6wACv+s49+MXtd0DDc0dHBcPvF5TyxzLwGMUSzRQCfdsilcB9WwZ5WBvjWdPz7 xAHlToVaYMZSJ1pkjeTm23/UU/re7PcNFaoeMIWkwewTX9GAnjkoacvxqm1ckEGz 3cdRtfzmCCauxY/inogkS0bB3XLMWvGjMWueh7IW/bcaCyzJQOkc9qJWSsOrAgo= =HO3c -----END PGP SIGNATURE----- From dougb at dougbarton.us Tue Oct 21 04:03:49 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Oct 2014 21:03:49 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <5445C933.4060200@nic-naa.net> References: <54458C12.7030003@dougbarton.us> <5445C933.4060200@nic-naa.net> Message-ID: <5445DB25.2040802@dougbarton.us> On 10/20/14 7:47 PM, Eric Brunner-Williams wrote: > having written the technical portion of winning proposal to ntia for the > .us zone, i differ. The plan I outlined was discussed about 2 years after Neustar took over management, and TMK was never actually discussed with Neustar. > as i recall, having done the research, in the year prior to the ntia's > tender some six people held some 40% of the major metro area subordinate > namespaces. to my chagrin, relieved by a notice of termination days > before my stock in the company vested, the winner adopted a > "orange-black" model, deprecating the namespace's existing hierarchical > registration model for a flat registration model. Yes, but the locality-based name space still exists. I used to hold some names under it, but gave them up when I moved out of state. Meanwhile, several states actively use their name space. But ... > the registration process model for .us is dissimilar to the registration > process models of .edu, .mil and .gov, as are the contractors to the > government. ... none of this is relevant to the proposal at hand. Neustar manages the domain on behalf of the USG. There is nothing preventing them from changing the way it is used, and the 10 year period I proposed takes runout of existing contracts into account (since EDU, GOV, and MIL would need continued operation during that period anyway). Doug From ankitagrawals at gmail.com Mon Oct 20 22:45:17 2014 From: ankitagrawals at gmail.com (Ankit Agrawal) Date: Tue, 21 Oct 2014 09:45:17 +1100 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: <08B26358-66E1-4967-AA19-C06E5FB58D3B@gmail.com> Hi Skeeve, Have you heard of Saisei (www.saisei.com)? They have a very good product that allows you to do this and much more in a virtualised environment. The software solution allows for very small to very large scale deployments and has a RESTful API for easy integration with your applications. They are getting a lot of traction with some of the major players in the industry around the globe. I can get you in touch with the right people if you like? Cheers, Ankit. On 21 Oct 2014, at 8:34 am, Skeeve Stevens wrote: > What I'd really love is a vAppliance. Some of these hardware solutions are > VERY expensive for offering only an average solution. I'd also rather not > rely on their hardware, but servers with VMware (or whatever) that we can > design our own redundancy. > > Does anyone know if Allot does a Virtual Appliance? > > I've also heard that pfSense is an interesting option... That could easily > be virtualised I would assume. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > On 20 October 2014 22:31, Nurul Islam Roman wrote: > >> Used following two product to shape traffic on packet level (L3). Had no >> issue with several thousand customer. >> >> Allot >> http://www.allot.com/netenforcer.html >> >> ET >> http://www.etinc.com/ >> >> Found "Allot" is very popular for satellite based Internet specially in >> south pacific island countries. >> >> -R >> >> >> On 20/10/14 2:55 PM, "Skeeve Stevens" >> wrote: >> >>> Hey all, >>> >>> Just wondering what/if people are using any shaping hardware/appliances >>> these days, and if so, what. >>> >>> I have a client which has thousands of customers on Satellite and needs to >>> restrict some users who are doing a lot. >>> >>> So I wanted to see what the current popular equipment out there is. >>> >>> ...Skeeve >>> >>> *Skeeve Stevens - *eintellego Networks Pty Ltd >>> skeeve at eintellegonetworks.com ; www.eintellegonetworks.com >>> >>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >>> >>> facebook.com/eintellegonetworks ; >>> linkedin.com/in/skeeve >>> >>> experts360: https://expert360.com/profile/d54a9 >>> >>> twitter.com/theispguy ; blog: www.theispguy.com >>> >>> >>> The Experts Who The Experts Call >>> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering >> From mkkaipov at gmail.com Tue Oct 21 02:58:11 2014 From: mkkaipov at gmail.com (=?UTF-8?B?0JzRg9GA0LDRgiDQmtCw0LjQv9C+0LI=?=) Date: Tue, 21 Oct 2014 06:58:11 +0400 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Hello Guys. What about DPI solutions? We use Cisco SCE8000 for traffic policing and billing purposes. Also, as we in MNO market we use PCRF tools too. Regards. 21 Окт 2014 г. 6:41 пользователь "Alex Nderitu" написал: > Not sure if Allot has GA on the virtual appliances but they did a demo > earlier this month > > http://www.allot.com/index.aspx?id=3797&itemID=158923 > On 21 Oct 2014 00:37, "Skeeve Stevens" < > skeeve+nanog at eintellegonetworks.com> > wrote: > > What I'd really love is a vAppliance. Some of these hardware solutions are > VERY expensive for offering only an average solution. I'd also rather not > rely on their hardware, but servers with VMware (or whatever) that we can > design our own redundancy. > > Does anyone know if Allot does a Virtual Appliance? > > I've also heard that pfSense is an interesting option... That could easily > be virtualised I would assume. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > On 20 October 2014 22:31, Nurul Islam Roman wrote: > > > Used following two product to shape traffic on packet level (L3). Had no > > issue with several thousand customer. > > > > Allot > > http://www.allot.com/netenforcer.html > > > > ET > > http://www.etinc.com/ > > > > Found "Allot" is very popular for satellite based Internet specially in > > south pacific island countries. > > > > -R > > > > > > On 20/10/14 2:55 PM, "Skeeve Stevens" > > wrote: > > > > >Hey all, > > > > > >Just wondering what/if people are using any shaping hardware/appliances > > >these days, and if so, what. > > > > > >I have a client which has thousands of customers on Satellite and needs > to > > >restrict some users who are doing a lot. > > > > > >So I wanted to see what the current popular equipment out there is. > > > > > >...Skeeve > > > > > >*Skeeve Stevens - *eintellego Networks Pty Ltd > > >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > > > > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > > > > >facebook.com/eintellegonetworks ; > > >linkedin.com/in/skeeve > > > > > >experts360: https://expert360.com/profile/d54a9 > > > > > >twitter.com/theispguy ; blog: www.theispguy.com > > > > > > > > >The Experts Who The Experts Call > > >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > > From rafael at gav.ufsc.br Tue Oct 21 04:38:02 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 20 Oct 2014 23:38:02 -0500 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Hello, I never used it. I always get a fresh install of FreeBSD and configure it from scratch so that it doesn't have all of the overhead from pfSense... Downside is that you have to configure it all by hand, but when all you need is one or two features, I prefer to do that instead. I usually go with pfSense for OpenVPN tunnels since it's just quicker with the GUI. On Mon, Oct 20, 2014 at 10:49 PM, Eduardo Schoedler wrote: > Em segunda-feira, 20 de outubro de 2014, Rafael Possamai < > rafael at gav.ufsc.br> escreveu: > >> Yes, pfSense can be virtualized. I did it once with VMWare to create a >> site2site tunnel, although I used Workstation 10 on Windows7 rather than >> the bare metal ESXi, but I wouldn't expect any changes. >> >> > What you think about BSDRP? It's another FreeBSD with ipfw and dummynet, > very ease to use for shaping. > > -- > Eduardo Schoedler > > > -- > Eduardo Schoedler > > From aftab.siddiqui at gmail.com Tue Oct 21 04:40:25 2014 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 21 Oct 2014 09:40:25 +0500 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Hi On Tue, Oct 21, 2014 at 7:58 AM, Мурат Каипов wrote: > Hello Guys. > What about DPI solutions? We use Cisco SCE8000 for traffic policing and > billing purposes. Also, as we in MNO market we use PCRF tools too. > > Cisco SCE8000 or even smaller boxes are pretty expensive and then require couple of other hardware to run the middleware which manages the device. Not a good idea. We bought it for the same purpose but its not scalable and very bulky in management. Regards, Aftab A. Siddiqui From brunner at nic-naa.net Tue Oct 21 04:52:38 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 20 Oct 2014 21:52:38 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <5445DB25.2040802@dougbarton.us> References: <54458C12.7030003@dougbarton.us> <5445C933.4060200@nic-naa.net> <5445DB25.2040802@dougbarton.us> Message-ID: <5445E696.9090807@nic-naa.net> i won't comment on your experience, having no direct knowledge. why you comment on mine is uninteresting. -e On 10/20/14 9:03 PM, Doug Barton wrote: > On 10/20/14 7:47 PM, Eric Brunner-Williams wrote: >> having written the technical portion of winning proposal to ntia for the >> .us zone, i differ. > > The plan I outlined was discussed about 2 years after Neustar took > over management, and TMK was never actually discussed with Neustar. > >> as i recall, having done the research, in the year prior to the ntia's >> tender some six people held some 40% of the major metro area subordinate >> namespaces. to my chagrin, relieved by a notice of termination days >> before my stock in the company vested, the winner adopted a >> "orange-black" model, deprecating the namespace's existing hierarchical >> registration model for a flat registration model. > > Yes, but the locality-based name space still exists. I used to hold > some names under it, but gave them up when I moved out of state. > Meanwhile, several states actively use their name space. But ... > >> the registration process model for .us is dissimilar to the registration >> process models of .edu, .mil and .gov, as are the contractors to the >> government. > > ... none of this is relevant to the proposal at hand. Neustar manages > the domain on behalf of the USG. There is nothing preventing them from > changing the way it is used, and the 10 year period I proposed takes > runout of existing contracts into account (since EDU, GOV, and MIL > would need continued operation during that period anyway). > > Doug > > > > From carlos at race.com Tue Oct 21 04:59:38 2014 From: carlos at race.com (Carlos Alcantar) Date: Tue, 21 Oct 2014 04:59:38 +0000 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: The platforms I¹ve seen used for large scale dpi is procera I¹ve heard rave reviews, but also comes with the price tag. http://www.proceranetworks.com Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 10/19/14, 9:55 PM, "Skeeve Stevens" wrote: >Hey all, > >Just wondering what/if people are using any shaping hardware/appliances >these days, and if so, what. > >I have a client which has thousands of customers on Satellite and needs to >restrict some users who are doing a lot. > >So I wanted to see what the current popular equipment out there is. > >...Skeeve > >*Skeeve Stevens - *eintellego Networks Pty Ltd >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > >facebook.com/eintellegonetworks ; >linkedin.com/in/skeeve > >experts360: https://expert360.com/profile/d54a9 > >twitter.com/theispguy ; blog: www.theispguy.com > > >The Experts Who The Experts Call >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > From ankitagrawals at gmail.com Tue Oct 21 05:01:35 2014 From: ankitagrawals at gmail.com (Ankit Agrawal) Date: Tue, 21 Oct 2014 16:01:35 +1100 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Hi Guys, Not sure if this got posted before as I didn't see it come in my Inbox. Have you heard of Saisei (www.saisei.com)? They have a very good product that allows you to do this and much more in a virtualised environment. The software solution allows for very small to very large scale deployments and has a RESTful API for easy integration with your applications. They are getting a lot of traction with some of the major players in the industry around the globe. I can get you in touch with the right people if you like? Cheers, Ankit. > On 21 Oct 2014, at 15:40, Aftab Siddiqui wrote: > > Hi > > On Tue, Oct 21, 2014 at 7:58 AM, Мурат Каипов wrote: > > >> Hello Guys. >> What about DPI solutions? We use Cisco SCE8000 for traffic policing and >> billing purposes. Also, as we in MNO market we use PCRF tools too. > Cisco SCE8000 or even smaller boxes are pretty expensive and then require > couple of other hardware to run the middleware which manages the device. > Not a good idea. We bought it for the same purpose but its not scalable and > very bulky in management. > > Regards, > > Aftab A. Siddiqui > Cisco SCE8000 or even smaller boxes are pretty expensive and then require > couple of other hardware to run the middleware which manages the device. > Not a good idea. We bought it for the same purpose but its not scalable and > very bulky in management. > > Regards, > > Aftab A. Siddiqui From bzs at world.std.com Tue Oct 21 05:18:16 2014 From: bzs at world.std.com (Barry Shein) Date: Tue, 21 Oct 2014 01:18:16 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> Message-ID: <21573.60568.636433.560229@world.std.com> Not that anyone is looking for a solution but I suppose one possible solution would be to use the two-letter cctld then gov like parliament.uk.gov or parliament.ca.gov etc. No doubt there would be some collisions but probably not too serious. -- -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 ag4ve.us at gmail.com Tue Oct 21 05:31:48 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 21 Oct 2014 01:31:48 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <5445D8DC.8050806@dougbarton.us> References: <54458C12.7030003@dougbarton.us> <5445D8DC.8050806@dougbarton.us> Message-ID: On Oct 20, 2014 11:54 PM, "Doug Barton" wrote: > > On 10/20/14 4:07 PM, shawn wilson wrote: >> >> >> Do we really have any prior examples that are even .1 the size of the >> usgov public system? Again, I'm not just referring to BIND and Windows >> DNS (and probably some Netware 4 etc stuff) - this would be web, soap >> parsers, email systems, vpn, and all of their clients (public, >> contractor, and gov). Anything close to what y'all are talking about? > > > Actually I think I could make a very convincing argument that GOV would not be the most challenging problem of the 3 I mentioned, but I won't. :) > You're right. But, edu and gov might be a tie with some obsolete tech they maintain that won't conform. But maybe not. As far as mil, I hold no clearance and if I did, I couldn't discuss even their public infrastructure (which AFAIK requires at least a public trust to work on). So I think leading this discussion to just the issues with gov (and maybe edu - but for some strange reason I have faith in them here) vs mil and edu as well...? > The question here is not, "Is it easy?" The questions are, "Is it the right thing to do?" and "Will it get easier to do tomorrow than it would have been to do today?" > No, the first question should be "is it possible" - we all seem to think its possible in some timeframe (though I wonder about the legality of changing active congressman's email). Next, is it the right thing - I'm going to go with yes, it probably is. But the later question is basically the cost benefit analysis - I'm just not sure if its worth it. And finally your question about time: > I can tell you beyond a shadow of a doubt that it would have been easier to do a decade ago, and 10 years from now it will be harder still. > Will it get easier/harder if we wait - I agree, it would've been easier 10 years ago and with the cheap IoT crap starting to come out (none that uses DNS yet, but) its not going to get any easier. If y'all disagree with me and feel there'd be a real benefit to doing this, the process should be started now. From jared at puck.nether.net Tue Oct 21 05:44:14 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 21 Oct 2014 01:44:14 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: > On Oct 20, 2014, at 9:30 PM, Bill Woodcock wrote: > > > On Oct 21, 2014, at 9:23 AM, Jared Mauch wrote: > >> Breaking tons of things is an interesting opinion of "why not”. > > Eh. Off the top of my head, I see two categories of breakage: > > 1) things that hard-code a list of “real” TLDs, and break when their expectations aren’t met, and > > 2) things that went ahead and trumped up their own non-canonical TLDs for their own purposes. > > Neither of those seem like practices worth defending, to me. Not worth going out of one’s way to break, either, but… > > And in the latter case, like “alternate roots,” that’s not an argument against creating more TLDs… They’ve already been created. It’s an argument against doing so in an uncoordinated manner, which is the source of the breakage. I’ve had operational issues introduced by *TLD operators and choices they made. I’m not going to document them here, but by using the root zone as a dumping ground for vanity addresses (e.g.: .google) highlights something that can be properly dealt with through normal processes. The number of things which will change from a predictable result to a unpredictable result (similar to when someone decided to wildcard .com) will continue to increase. Thankfully we can now receive email from spammer at example.google as it properly resolves and validates(!). (this is just one example). - Jared From randy at psg.com Tue Oct 21 05:44:57 2014 From: randy at psg.com (Randy Bush) Date: Tue, 21 Oct 2014 14:44:57 +0900 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: systemd is insanity. one would have hoped that deb and others would know better. sigh. vmlinux.el here we come! randy From Valdis.Kletnieks at vt.edu Tue Oct 21 13:40:30 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 21 Oct 2014 09:40:30 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Your message of "Tue, 21 Oct 2014 14:44:57 +0900." References: <5445AD63.7090400@lugosys.com> Message-ID: <66189.1413898830@turing-police.cc.vt.edu> On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: > systemd is insanity. one would have hoped that deb and others would > know better. sigh. It started as a replacement init system. I suspected it had jumped the shark when it sprouted an entirely new DHCP and NTP service. And this was confirmed when I saw this: "Leading up to this has been cursor rendering support, keyboard mapping support, screen renderer, DRM back-end, input interface, and dozens of other commits." http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ When your init system is worrying about cursor rendering, you have truly fallen victim to severe feature bloat. I guess Jamie Zawinski was right: "Every program attempts to expand until it can read mail." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mfidelman at meetinghouse.net Tue Oct 21 13:51:05 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 09:51:05 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <66189.1413898830@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <544664C9.1040802@meetinghouse.net> Valdis.Kletnieks at vt.edu wrote: > On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: >> systemd is insanity. one would have hoped that deb and others would >> know better. sigh. > It started as a replacement init system. I suspected it had jumped > the shark when it sprouted an entirely new DHCP and NTP service. And this > was confirmed when I saw this: > > "Leading up to this has been cursor rendering support, keyboard mapping > support, screen renderer, DRM back-end, input interface, and dozens of other > commits." > > http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ > > When your init system is worrying about cursor rendering, you have truly > fallen victim to severe feature bloat. I guess Jamie Zawinski was right: > "Every program attempts to expand until it can read mail." Actually - this kind of sums it all up: http://www.muylinux.com/wp-content/uploads/2014/08/funny-systemd.gif Good for a morning laugh. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From josh at imaginenetworksllc.com Tue Oct 21 05:02:03 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 21 Oct 2014 01:02:03 -0400 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: Procera is probably the best product for real DPI. The key is the signatures. It matches everything so granular it's simply fantastic. Right down to what update you're grabbing for your iPhone. As was said, you'll be paying for it. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Oct 21, 2014 1:00 AM, "Carlos Alcantar" wrote: > The platforms I¹ve seen used for large scale dpi is procera I¹ve heard > rave reviews, but also comes with the price tag. > > > http://www.proceranetworks.com > > > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > > > > > On 10/19/14, 9:55 PM, "Skeeve Stevens" > wrote: > > >Hey all, > > > >Just wondering what/if people are using any shaping hardware/appliances > >these days, and if so, what. > > > >I have a client which has thousands of customers on Satellite and needs to > >restrict some users who are doing a lot. > > > >So I wanted to see what the current popular equipment out there is. > > > >...Skeeve > > > >*Skeeve Stevens - *eintellego Networks Pty Ltd > >skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > > >Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > > >facebook.com/eintellegonetworks ; > >linkedin.com/in/skeeve > > > >experts360: https://expert360.com/profile/d54a9 > > > >twitter.com/theispguy ; blog: www.theispguy.com > > > > > >The Experts Who The Experts Call > >Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > > > From stephan008 at gmx.com Tue Oct 21 10:52:58 2014 From: stephan008 at gmx.com (Stephan Alz) Date: Tue, 21 Oct 2014 12:52:58 +0200 Subject: [DHCP Relay agent] send packets to different dhcp servers based on client options Message-ID: Hello Folks, I looking for an opensource project (can be a modification of the original isc-relay agent), which able to send packets to different DHCP servers based on DHCP options such as: The Vendor Class Identifier (Option 60) Vendor Class Identifier (Option 60) can be used by DHCP clients to identify the vendor and functionality of a DHCP client. The information is a variable length string of characters or octets which has a meaning specified by the vendor of the DHCP client. If my vendor class identifier contains lets say: "motorola.fw0512.5112" string, send it to DHCP server 1 on ip 192.168.1.1 "cisco.fw06411.111" string, send it to DHCP server 2 on ip 172.16.15.44 The existent relay agents (isc-relay, dhcp-helper) send a copy of all the dhcp servers of the dhcpdiscover message. This is definitely not what I want. Thanks! From vristevs at ramapo.edu Tue Oct 21 14:20:55 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 21 Oct 2014 10:20:55 -0400 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: <54466BC7.6010400@ramapo.edu> We've used a few over the years. We had Packeteer Packetshapers originally but they became way too expensive once Bluecoat acquired them. $50,000 for an appliance to shape a 1 gig pipe. IIRC,$10,000 per year on maintenance at the time. These prices are after discount.We looked at the following to replace them. NetEqualizer Procera Exinda We went with Exinda and I like the solution. These days, I rely on it more for reporting and traffic/protocol analysis than for shaping, but the shaping does work as advertised. Keep in mind, these solutions can't shape on asymmetric traffic since they need to see the entire flow. If you have a pair of links, you'll need to cluster a pair of shapers so they can share flow information. I also have tested out the traffic shaping on PFSense VMs and it works. I never pushed production traffic through them but my home firewall is a PFSense VM and the shaping works there. Not sure how it would handle a large number of clients though. On 10/20/2014 12:55 AM, Skeeve Stevens wrote: > Hey all, > > Just wondering what/if people are using any shaping hardware/appliances > these days, and if so, what. > > I have a client which has thousands of customers on Satellite and needs to > restrict some users who are doing a lot. > > So I wanted to see what the current popular equipment out there is. > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering From dwhite at olp.net Tue Oct 21 14:45:04 2014 From: dwhite at olp.net (Dan White) Date: Tue, 21 Oct 2014 09:45:04 -0500 Subject: send packets to different dhcp servers based on client options In-Reply-To: References: Message-ID: <20141021144504.GC3636@dan.olp.net> On 10/21/14 12:52 +0200, Stephan Alz wrote: >If my vendor class identifier contains lets say: > > "motorola.fw0512.5112" string, send it to DHCP server 1 on ip 192.168.1.1 > "cisco.fw06411.111" string, send it to DHCP server 2 on ip 172.16.15.44 > >The existent relay agents (isc-relay, dhcp-helper) send a copy of all the >dhcp servers of the dhcpdiscover message. This is definitely not what I >want. For ISC DHCP servers, turning off the 'authoritative' statement will prevent the server from issuing DHCPNAKs, and should essentially allow each server to ignore requests from unknown clients. See dhcpd.conf(5). -- Dan White From drc at virtualized.org Tue Oct 21 15:08:09 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 21 Oct 2014 08:08:09 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <21573.60568.636433.560229@world.std.com> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> Message-ID: On Oct 20, 2014, at 10:18 PM, Barry Shein wrote: > Not that anyone is looking for a solution but I suppose one possible > solution would be to use the two-letter cctld then gov like > parliament.uk.gov or parliament.ca.gov etc. > > No doubt there would be some collisions but probably not too serious. Folks outside of the US have issues with the US government having a role in the administration of the root, even if that role is to ensure ICANN does screw the pooch. Having country governments use .GOV would, assuming .GOV was still managed by the USG, give the US government vastly greater and more direct control of the country's government's websites (not to mention a lovely source of metadata associated with lookups of those websites). Moving .GOV away from USG control is both wildly unlikely and pointless, particularly in a world of 400+ (and counting) TLDs. AFAIK, reasons why the FNC decided to assert GOV and MIL were to be US-only were probably because the USG had already been using it, the operational value of switching would be low while the cost would've been high, some other governments were already using sub-domains within their ccTLDs, and/or it was seen as a good thing to encourage more ccTLD delegations and the use of those ccTLDs. The fact that it gives some political folk ammunition to complain about how the Internet is "controlled" by the USG is merely a side benefit (to them). Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dougb at dougbarton.us Tue Oct 21 17:16:50 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 21 Oct 2014 10:16:50 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> Message-ID: <54469502.3030205@dougbarton.us> On 10/21/14 8:08 AM, David Conrad wrote: > Folks outside of the US have issues with the US government having a > role in the administration of the root, even if that role is to > ensure ICANN does screw the pooch. Freudian slip, David? :) Doug From israel.lugo at lugosys.com Tue Oct 21 17:17:09 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Tue, 21 Oct 2014 18:17:09 +0100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <66189.1413898830@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <54469515.5020104@lugosys.com> I was actually not aware of this. I've been told that systemd also includes fsck's functionality (or is planning to?). That just seems absurd to me. I didn't really have a strong opinion on either side of this yet. Seeing the replies from other people here, though, and reading some more about it, this seems to be a very bad idea. The binary logs for example worry me, especially corruption issues: http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/ https://bbs.archlinux.org/viewtopic.php?id=169966 On 21-10-2014 14:40, Valdis.Kletnieks at vt.edu wrote: > On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: >> systemd is insanity. one would have hoped that deb and others would >> know better. sigh. > It started as a replacement init system. I suspected it had jumped > the shark when it sprouted an entirely new DHCP and NTP service. And this > was confirmed when I saw this: > > "Leading up to this has been cursor rendering support, keyboard mapping > support, screen renderer, DRM back-end, input interface, and dozens of other > commits." > > http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ > > When your init system is worrying about cursor rendering, you have truly > fallen victim to severe feature bloat. I guess Jamie Zawinski was right: > "Every program attempts to expand until it can read mail." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Tue Oct 21 17:19:07 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 21 Oct 2014 10:19:07 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <648FFDA5-31F1-4DB6-8D9B-03AE708FCDAC@cisco.com> <80D92A82-5D15-48B5-A7E3-24B17CC90124@isi.edu> <1F797F18-CBE8-4A8E-9E96-0802849275F4@pch.net> Message-ID: <5446958B.5010801@dougbarton.us> On 10/20/14 10:44 PM, Jared Mauch wrote: > I’ve had operational issues introduced by *TLD operators and choices they made. When that happens, report them to ICANN's SSAC. They take the "Stability" part of their name seriously. That said, new TLDs are not going away, so operations needs to take that into account. Doug From dougb at dougbarton.us Tue Oct 21 17:20:23 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 21 Oct 2014 10:20:23 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <5445E696.9090807@nic-naa.net> References: <54458C12.7030003@dougbarton.us> <5445C933.4060200@nic-naa.net> <5445DB25.2040802@dougbarton.us> <5445E696.9090807@nic-naa.net> Message-ID: <544695D7.1060704@dougbarton.us> The fact that you think I'm commenting about you at all is illuminating :) On 10/20/14 9:52 PM, Eric Brunner-Williams wrote: > i won't comment on your experience, having no direct knowledge. why you > comment on mine is uninteresting. > > -e > > On 10/20/14 9:03 PM, Doug Barton wrote: >> On 10/20/14 7:47 PM, Eric Brunner-Williams wrote: >>> having written the technical portion of winning proposal to ntia for the >>> .us zone, i differ. >> >> The plan I outlined was discussed about 2 years after Neustar took >> over management, and TMK was never actually discussed with Neustar. >> >>> as i recall, having done the research, in the year prior to the ntia's >>> tender some six people held some 40% of the major metro area subordinate >>> namespaces. to my chagrin, relieved by a notice of termination days >>> before my stock in the company vested, the winner adopted a >>> "orange-black" model, deprecating the namespace's existing hierarchical >>> registration model for a flat registration model. >> >> Yes, but the locality-based name space still exists. I used to hold >> some names under it, but gave them up when I moved out of state. >> Meanwhile, several states actively use their name space. But ... >> >>> the registration process model for .us is dissimilar to the registration >>> process models of .edu, .mil and .gov, as are the contractors to the >>> government. >> >> ... none of this is relevant to the proposal at hand. Neustar manages >> the domain on behalf of the USG. There is nothing preventing them from >> changing the way it is used, and the 10 year period I proposed takes >> runout of existing contracts into account (since EDU, GOV, and MIL >> would need continued operation during that period anyway). >> >> Doug From sandy at tislabs.com Tue Oct 21 17:33:21 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 21 Oct 2014 13:33:21 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> Message-ID: <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> On Oct 21, 2014, at 11:08 AM, David Conrad wrote: > On Oct 20, 2014, at 10:18 PM, Barry Shein wrote: >> Not that anyone is looking for a solution but I suppose one possible >> solution would be to use the two-letter cctld then gov like >> parliament.uk.gov or parliament.ca.gov etc. >> >> No doubt there would be some collisions but probably not too serious. > > Folks outside of the US have issues with the US government having a role in the administration of the root, even if that role is to ensure ICANN does screw the pooch. I'm thinking there's a "not" missing here. --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alter3d at alter3d.ca Tue Oct 21 17:42:38 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 21 Oct 2014 13:42:38 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> Message-ID: <54469B0E.4040108@alter3d.ca> On 10/21/2014 01:33 PM, Sandra Murphy wrote: > On Oct 21, 2014, at 11:08 AM, David Conrad wrote: > >> On Oct 20, 2014, at 10:18 PM, Barry Shein wrote: >>> Not that anyone is looking for a solution but I suppose one possible >>> solution would be to use the two-letter cctld then gov like >>> parliament.uk.gov or parliament.ca.gov etc. >>> >>> No doubt there would be some collisions but probably not too serious. >> Folks outside of the US have issues with the US government having a role in the administration of the root, even if that role is to ensure ICANN does screw the pooch. > I'm thinking there's a "not" missing here. > > --Sandy Depends on whether we're talking about the nominal or effective role of government... ;) - Peter From drc at virtualized.org Tue Oct 21 18:17:13 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 21 Oct 2014 11:17:13 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> Message-ID: <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> On Oct 21, 2014, at 10:33 AM, Sandra Murphy wrote: >> Folks outside of the US have issues with the US government having a role in the administration of the root, even if that role is to ensure ICANN does screw the pooch. > > I'm thinking there's a "not" missing here. For the numerous people who have suggested similar, both publicly and privately: yes, I did accidentally leave out a teensy little word. I honestly wasn't making a comment about my current (perhaps until my boss reads the post) employer. Really. No, really. That'll teach me to post pre-coffee. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rafael at gav.ufsc.br Tue Oct 21 18:57:57 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 21 Oct 2014 13:57:57 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: Perhaps they could make a "desktop" version with systemd if the devs want it that bad, but it'd be a shame if they ruined it for everyone that uses Debian as a server as well. Haven't installed x on Debian since Etch... o.O On Tue, Oct 21, 2014 at 12:44 AM, Randy Bush wrote: > systemd is insanity. one would have hoped that deb and others would > know better. sigh. > > vmlinux.el here we come! > > randy > From bzs at world.std.com Tue Oct 21 19:11:55 2014 From: bzs at world.std.com (Barry Shein) Date: Tue, 21 Oct 2014 15:11:55 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: <21574.45051.625317.910556@world.std.com> I've done a fair amount of hand-to-hand combat with systemd. When it's good it's good, tho not always apparent why it's good. But for example some of my servers boot in seconds. When it's bad it can be painful and incredibly opaque and a huge time sink. Googling for suggestions I've found several threads where the co-author (Poettering) jumps in usually to be annoyingly arrogant (I'm sure he's very bright and good to children and pets and overworked) responding with comments like why don't you just read your logs and not bother this list or similar (that was paraphrased.) The logs are, in my experience, almost always useless or nearly so, "mumble failed to start" basically. I'm not the only one: http://www.muktware.com/2014/04/linus-torvalds-happy-systemd-author-kay-sievers/25151 It also resists tools like strace because it tends to do things by IPC. In one extreme case I just reworked an /etc/init.d script to avoid systemd (not use the various /etc/rc.foo files), mostly just hit it with a sledgehammer and put fixing that on my TODO list. Unfortunately I am mortal and have limited time on this earth. My experience as I said is mixed, hard cases are very hard where they really seem like they shouldn't be (just tell me roughly what you're trying to do rather than just fail, eg, via some debug enable), most are just your usual oops it wants this or that situations. I don't think I'd want to revert to sysvinit, systemd seems architecturally superior. But it needs a lot more transparency and some attempt to gather common problems -- like why is it hanging asking for a password on the console when I can't see why it thinks it needs one? -- and FAQ them with real answers or add some code/configuration to fix that (never ask for a password in this script OK? And no --no-ask-password isn't fixing this so stop repeating that answer!) -- -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 jfbeam at gmail.com Tue Oct 21 19:31:23 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Oct 2014 15:31:23 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: On Tue, 21 Oct 2014 01:44:57 -0400, Randy Bush wrote: > systemd is insanity. one would have hoped that deb and others would > know better. sigh. This is exactly the type of shit one gets by letting non-technical people make technical decisions. systemd should never have even been on the table. If you want a MacOSX style launcher, then build one; it doesn't need to replace init or be pid 1. From eugen at imacandi.net Tue Oct 21 19:41:16 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 21 Oct 2014 22:41:16 +0300 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <66189.1413898830@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: On Tue, Oct 21, 2014 at 4:40 PM, wrote: > > http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ > > When your init system is worrying about cursor rendering, you have truly > fallen victim to severe feature bloat. I guess Jamie Zawinski was right: > "Every program attempts to expand until it can read mail." > I think systemd wants to become the next Emacs ;)) From jimpop at gmail.com Tue Oct 21 19:47:08 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 21 Oct 2014 15:47:08 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: On Tue, Oct 21, 2014 at 3:41 PM, Eugeniu Patrascu wrote: > > I think systemd wants to become the next Emacs ;)) Or the next user activity collection point. Systemd really is a black hole to 99.9% of the people who will use/deploy it... seems perfect for lots of things. -Jim P. From owen at delong.com Tue Oct 21 19:55:02 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Oct 2014 12:55:02 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54469515.5020104@lugosys.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> Message-ID: <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> Wait… Let me see if I understand this correctly… 1. Move fsck functionality into systemd 2. Have it generate opaque binary logs 3. If your filesystem is corrupted in a way that systems can’t repair, you can’t even read the logs of what systemd saw or did? Yeah, that sounds like a very definite “bad thing”. Owen On Oct 21, 2014, at 10:17 AM, Israel G. Lugo wrote: > I was actually not aware of this. I've been told that systemd also > includes fsck's functionality (or is planning to?). That just seems > absurd to me. > > I didn't really have a strong opinion on either side of this yet. Seeing > the replies from other people here, though, and reading some more about > it, this seems to be a very bad idea. > > The binary logs for example worry me, especially corruption issues: > > http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/ > https://bbs.archlinux.org/viewtopic.php?id=169966 > > > > On 21-10-2014 14:40, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: >>> systemd is insanity. one would have hoped that deb and others would >>> know better. sigh. >> It started as a replacement init system. I suspected it had jumped >> the shark when it sprouted an entirely new DHCP and NTP service. And this >> was confirmed when I saw this: >> >> "Leading up to this has been cursor rendering support, keyboard mapping >> support, screen renderer, DRM back-end, input interface, and dozens of other >> commits." >> >> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ >> >> When your init system is worrying about cursor rendering, you have truly >> fallen victim to severe feature bloat. I guess Jamie Zawinski was right: >> "Every program attempts to expand until it can read mail." > > From asullivan at dyn.com Tue Oct 21 20:10:21 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Tue, 21 Oct 2014 16:10:21 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <21574.45051.625317.910556@world.std.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> Message-ID: <20141021201019.GE36267@dyn.com> On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: > But > for example some of my servers boot in seconds. One is reminded of a mail, included in the Preface to _The UNIX-HATERS Handbook_, available at http://www.art.net/~hopkins/Don/unix-haters/preface.html. Apparently, things really are going to get a lot worse before they get worse. Best regards, A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From contact at nullivex.com Tue Oct 21 20:18:40 2014 From: contact at nullivex.com (Bryan Tong) Date: Tue, 21 Oct 2014 14:18:40 -0600 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> Message-ID: I have been working with developing systems that boot with Linux for a number of years on a multitude of distributions and I never saw a problem with the tools or the process. Purely the lack of standards. It seems stubborn at the least to propose an opaque software solution when a simple standards organization for how to structure the init system is all that is required. Why not write high level code to manage standardized scripts rather than replace them with binary darkness. The only reason we have desktop Linux is due to the flexibility of the Unix architecture, seems silly to abandon that now. The pure fact of it is that developers hate messing with text because its unpredictable and prone to bugs. However with standards and possibly a decent meta format (I look towards YML, XML, JSON) that can be consumed and produced with scripts there should be no issues. The final fact is that bash itself is a dirty language that developers hate and system administrators love. Its a gross blend of programming functionality mixed with command line awareness and its unpredictable, especially at the code generation level. Its also too sensitive to text formatting and line endings. In conclusion, we will continue to deploy our scripts to a number of Linux distributions and have came to the conclusion that it is simply cheaper to have a human deal with the actual deployment of the system rather than write host of deployment code to cover every system. End users know how to use their system and we rely on that. Finally, why not focus on creating and maintaining collaborative unbiased standards rather than parading egos and hurting communities. On Tue, Oct 21, 2014 at 1:55 PM, Owen DeLong wrote: > Wait… Let me see if I understand this correctly… > > 1. Move fsck functionality into systemd > 2. Have it generate opaque binary logs > 3. If your filesystem is corrupted in a way that systems can’t > repair, you can’t even read the logs of what systemd saw or did? > > Yeah, that sounds like a very definite “bad thing”. > > Owen > > On Oct 21, 2014, at 10:17 AM, Israel G. Lugo > wrote: > > > I was actually not aware of this. I've been told that systemd also > > includes fsck's functionality (or is planning to?). That just seems > > absurd to me. > > > > I didn't really have a strong opinion on either side of this yet. Seeing > > the replies from other people here, though, and reading some more about > > it, this seems to be a very bad idea. > > > > The binary logs for example worry me, especially corruption issues: > > > > > http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/ > > https://bbs.archlinux.org/viewtopic.php?id=169966 > > > > > > > > On 21-10-2014 14:40, Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: > >>> systemd is insanity. one would have hoped that deb and others would > >>> know better. sigh. > >> It started as a replacement init system. I suspected it had jumped > >> the shark when it sprouted an entirely new DHCP and NTP service. And > this > >> was confirmed when I saw this: > >> > >> "Leading up to this has been cursor rendering support, keyboard mapping > >> support, screen renderer, DRM back-end, input interface, and dozens of > other > >> commits." > >> > >> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ > >> > >> When your init system is worrying about cursor rendering, you have truly > >> fallen victim to severe feature bloat. I guess Jamie Zawinski was > right: > >> "Every program attempts to expand until it can read mail." > > > > > > -- eSited LLC (701) 390-9638 From joe at via.net Tue Oct 21 20:26:58 2014 From: joe at via.net (joe mcguckin) Date: Tue, 21 Oct 2014 13:26:58 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <714D1E87-2BB7-4127-83BF-512555B9388C@via.net> Why not write it in Emacs? Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Oct 21, 2014, at 12:41 PM, Eugeniu Patrascu wrote: > On Tue, Oct 21, 2014 at 4:40 PM, wrote: > >> >> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ >> >> When your init system is worrying about cursor rendering, you have truly >> fallen victim to severe feature bloat. I guess Jamie Zawinski was right: >> "Every program attempts to expand until it can read mail." >> > > I think systemd wants to become the next Emacs ;)) From morrowc.lists at gmail.com Tue Oct 21 20:43:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Oct 2014 16:43:21 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <20141021201019.GE36267@dyn.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> Message-ID: On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan wrote: > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: >> But >> for example some of my servers boot in seconds. > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS > Handbook_, available at it's really not clear to me that 'reboots in seconds' is a thing to optimize... I suppose the win is: "Is the startup/shutdown process clear, conscise and understandable at 3am local time?" followed by: "Can I adjust my startup processes to meet my needs easily and without finding a phd in unix?" If systemd is simply a change in how I think about /etc/init.d/* and /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility then it's a fail. -chris From brunner at nic-naa.net Tue Oct 21 20:44:17 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 21 Oct 2014 13:44:17 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: <5446C5A1.3040801@nic-naa.net> > systemd is insanity. see also smit. From nanog at konadogs.net Tue Oct 21 20:53:11 2014 From: nanog at konadogs.net (Nate Itkin) Date: Tue, 21 Oct 2014 10:53:11 -1000 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5446C5A1.3040801@nic-naa.net> References: <5445AD63.7090400@lugosys.com> <5446C5A1.3040801@nic-naa.net> Message-ID: <20141021205311.GA6028@li92-81.konadogs.net> Often presented with an alternate spelling from those of us who had to live with it. On Tue, Oct 21, 2014 at 01:44:17PM -0700, Eric Brunner-Williams wrote: > >systemd is insanity. > > see also smit. From mfidelman at meetinghouse.net Tue Oct 21 20:56:24 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 16:56:24 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> Message-ID: <5446C878.6020201@meetinghouse.net> Christopher Morrow wrote: > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan wrote: >> On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: >>> But >>> for example some of my servers boot in seconds. >> One is reminded of a mail, included in the Preface to _The UNIX-HATERS >> Handbook_, available at > it's really not clear to me that 'reboots in seconds' is a thing to optimize... > > I suppose the win is: > "Is the startup/shutdown process clear, conscise and understandable > at 3am local time?" > > followed by: > "Can I adjust my startup processes to meet my needs easily and > without finding a phd in unix?" > > If systemd is simply a change in how I think about /etc/init.d/* and > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility > then it's a fail. > You guys REALLY don't want to wade into the swamp on debian-users -- the place is full of systemd fanboys and apologists, and anybody who raises real operational concerns resulting from the switch in default init systems. I'm really pining for a LISP Machine right about now. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tagno25 at gmail.com Tue Oct 21 21:36:20 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Tue, 21 Oct 2014 16:36:20 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141021205311.GA6028@li92-81.konadogs.net> References: <5445AD63.7090400@lugosys.com> <5446C5A1.3040801@nic-naa.net> <20141021205311.GA6028@li92-81.konadogs.net> Message-ID: Could someone comment on why they chose systemd over upstart (other than the Canonical CLA)? Or point to an article on it? From mfidelman at meetinghouse.net Tue Oct 21 22:00:22 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 18:00:22 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5446C5A1.3040801@nic-naa.net> <20141021205311.GA6028@li92-81.konadogs.net> Message-ID: <5446D776.5090600@meetinghouse.net> Philip Dorr wrote: > Could someone comment on why they chose systemd over upstart (other > than the Canonical CLA)? Or point to an article on it? If you want to wade into the mess, the archives of the Debian Tech. Committee (https://lists.debian.org/debian-ctte/), for Dec 2013-March 2014, make for some interesting reading (if you have a Baroque sense of what's interesting). The voting is documented here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 (I think - Debian decision making is incredibly convoluted.) This article has some background that's reasonably accurate: http://www.zdnet.com/debian-inches-towards-new-init-system-decision-amid-fallout-7000026128/ I seem to recall a summary document comparing the various available init systems, and how systemd came out on top - but I'll be damned if I can find it now. Some of the position statements are linked from here: https://wiki.debian.org/Debate/initsystem Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jra at baylink.com Tue Oct 21 22:29:44 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 21 Oct 2014 18:29:44 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: <21574.45051.625317.910556@world.std.com> Message-ID: <9889181.6613.1413930584963.JavaMail.root@benjamin.baylink.com> The thing that I don't understand about systemd is how it managed to get *EVERY SINGLE DISTRIBUTION'S RELEASE MANAGER* on board in less than a year, given how thoroughly it violates the Unix philosophy, and how poorly documented it is -- to the point where you can't even run sysvinit anymore unless you're willing to build initscripts by hand, since packages don't even include them anymore. Does Poettering have compromising photographs of all these guys in a puppy pile at a Linuxcon somewhere? Cheers, -- jra ----- Original Message ----- > From: "Barry Shein" > To: "Israel G. Lugo" > Cc: nanog at nanog.org > Sent: Tuesday, October 21, 2014 3:11:55 PM > Subject: Re: Linux: concerns over systemd [OT] > I've done a fair amount of hand-to-hand combat with systemd. > > When it's good it's good, tho not always apparent why it's good. But > for example some of my servers boot in seconds. > > When it's bad it can be painful and incredibly opaque and a huge time > sink. > > Googling for suggestions I've found several threads where the > co-author (Poettering) jumps in usually to be annoyingly arrogant (I'm > sure he's very bright and good to children and pets and overworked) > responding with comments like why don't you just read your logs and > not bother this list or similar (that was paraphrased.) The logs are, > in my experience, almost always useless or nearly so, "mumble failed > to start" basically. > > I'm not the only one: > > http://www.muktware.com/2014/04/linus-torvalds-happy-systemd-author-kay-sievers/25151 > > It also resists tools like strace because it tends to do things by > IPC. In one extreme case I just reworked an /etc/init.d script to > avoid systemd (not use the various /etc/rc.foo files), mostly just hit > it with a sledgehammer and put fixing that on my TODO > list. Unfortunately I am mortal and have limited time on this earth. > > My experience as I said is mixed, hard cases are very hard where they > really seem like they shouldn't be (just tell me roughly what you're > trying to do rather than just fail, eg, via some debug enable), most > are just your usual oops it wants this or that situations. > > I don't think I'd want to revert to sysvinit, systemd seems > architecturally superior. > > But it needs a lot more transparency and some attempt to gather common > problems -- like why is it hanging asking for a password on the > console when I can't see why it thinks it needs one? -- and FAQ them > with real answers or add some code/configuration to fix that (never > ask for a password in this script OK? And no --no-ask-password isn't > fixing this so stop repeating that answer!) > > -- > -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* -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Tue Oct 21 22:55:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 21 Oct 2014 18:55:56 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: <5446E23A.50407@lugosys.com> Message-ID: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Capi" > On 10/21/2014 11:29 PM, Jay Ashworth wrote: > > The thing that I don't understand about systemd is how it managed to > > get > > *EVERY SINGLE DISTRIBUTION'S RELEASE MANAGER* on board in less than > > a year, > > given how thoroughly it violates the Unix philosophy, and how poorly > > documented it is > > Not *every single* distribution... I had meant to put an asterisk on that. > I'm glad to be using Gentoo Linux at home for the last 10 years... > They've adopted OpenRC, which is much less invasive, works with an > existing init (possibly sysv) and uses the friendly shell scripts > we're all used to. Ok, but how does it handle providing initscripts? I gather any upstreams which used to provide them aren't anymore... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From tom at ninjabadger.net Tue Oct 21 22:59:44 2014 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 21 Oct 2014 23:59:44 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> Message-ID: <5446E560.8080501@ninjabadger.net> On 21/10/14 23:55, Jay Ashworth wrote: > Ok, but how does it handle providing initscripts? I gather any upstreams > which used to provide them aren't anymore... It's Gentoo: "You should write your own" is the most likely answer. -- Tom From mfidelman at meetinghouse.net Tue Oct 21 23:13:38 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 19:13:38 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <9889181.6613.1413930584963.JavaMail.root@benjamin.baylink.com> References: <9889181.6613.1413930584963.JavaMail.root@benjamin.baylink.com> Message-ID: <5446E8A2.9020806@meetinghouse.net> Probably a lot of it has to do with: - we're merging udev and a bunch of other things into systemd - you want GNOME to work, you'd better use systemd - Canonical (Ubuntu) DIDN'T commit to udev until Debian made the decision - they would have kept going with upstart, but when Debian committed, they decided they didn't want to support a now-orphaned init system - Gentoo supports systemd as an option, it's fork funtoo doesn't - Slackware doesn't Miles Fidelman Jay Ashworth wrote: > The thing that I don't understand about systemd is how it managed to get > *EVERY SINGLE DISTRIBUTION'S RELEASE MANAGER* on board in less than a year, > given how thoroughly it violates the Unix philosophy, and how poorly > documented it is -- to the point where you can't even run sysvinit anymore > unless you're willing to build initscripts by hand, since packages don't > even include them anymore. > > Does Poettering have compromising photographs of all these guys in a > puppy pile at a Linuxcon somewhere? > > Cheers, > -- jra > > ----- Original Message ----- >> From: "Barry Shein" >> To: "Israel G. Lugo" >> Cc: nanog at nanog.org >> Sent: Tuesday, October 21, 2014 3:11:55 PM >> Subject: Re: Linux: concerns over systemd [OT] >> I've done a fair amount of hand-to-hand combat with systemd. >> >> When it's good it's good, tho not always apparent why it's good. But >> for example some of my servers boot in seconds. >> >> When it's bad it can be painful and incredibly opaque and a huge time >> sink. >> >> Googling for suggestions I've found several threads where the >> co-author (Poettering) jumps in usually to be annoyingly arrogant (I'm >> sure he's very bright and good to children and pets and overworked) >> responding with comments like why don't you just read your logs and >> not bother this list or similar (that was paraphrased.) The logs are, >> in my experience, almost always useless or nearly so, "mumble failed >> to start" basically. >> >> I'm not the only one: >> >> http://www.muktware.com/2014/04/linus-torvalds-happy-systemd-author-kay-sievers/25151 >> >> It also resists tools like strace because it tends to do things by >> IPC. In one extreme case I just reworked an /etc/init.d script to >> avoid systemd (not use the various /etc/rc.foo files), mostly just hit >> it with a sledgehammer and put fixing that on my TODO >> list. Unfortunately I am mortal and have limited time on this earth. >> >> My experience as I said is mixed, hard cases are very hard where they >> really seem like they shouldn't be (just tell me roughly what you're >> trying to do rather than just fail, eg, via some debug enable), most >> are just your usual oops it wants this or that situations. >> >> I don't think I'd want to revert to sysvinit, systemd seems >> architecturally superior. >> >> But it needs a lot more transparency and some attempt to gather common >> problems -- like why is it hanging asking for a password on the >> console when I can't see why it thinks it needs one? -- and FAQ them >> with real answers or add some code/configuration to fix that (never >> ask for a password in this script OK? And no --no-ask-password isn't >> fixing this so stop repeating that answer!) >> >> -- >> -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* -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From israel.lugo at lugosys.com Tue Oct 21 23:38:11 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Wed, 22 Oct 2014 00:38:11 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> Message-ID: <5446EE63.20507@lugosys.com> On 10/21/2014 11:55 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Capi" Whoops, used the wrong alias to reply. >> Not *every single* distribution... > I had meant to put an asterisk on that. My remark was meant to be tongue-in-cheek :) > Ok, but how does it handle providing initscripts? I gather any upstreams > which used to provide them aren't anymore... The Gentoo devs take care of that. I presume they reuse what they can from upstream... They do a lot of hard work (sometimes more work than they have the manpower for, unfortunately). I remember, for example, back in KDE 3.5 days they were already dividing the upstream KDE mega packages (kde-games, kde-office) into individual packages, so you could choose specific programs instead of 300 MB bundles. From jfbeam at gmail.com Tue Oct 21 23:56:27 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Oct 2014 19:56:27 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <9889181.6613.1413930584963.JavaMail.root@benjamin.baylink.com> References: <9889181.6613.1413930584963.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, 21 Oct 2014 18:29:44 -0400, Jay Ashworth wrote: > The thing that I don't understand about systemd is how it managed to get > *EVERY SINGLE DISTRIBUTION'S RELEASE MANAGER* on board... It's spelled "Red Hat". Add in GNOME and debian (et. al.) is backed into a corner. Red Hat is soo f'ing big, pretty much every project under the sun is going to stop maintaining scripts in favor of systemd. From israel.lugo at lugosys.com Tue Oct 21 23:57:17 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Wed, 22 Oct 2014 00:57:17 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5446E560.8080501@ninjabadger.net> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> <5446E560.8080501@ninjabadger.net> Message-ID: <5446F2DD.7060101@lugosys.com> On 10/21/2014 11:59 PM, Tom Hill wrote: > On 21/10/14 23:55, Jay Ashworth wrote: >> Ok, but how does it handle providing initscripts? I gather any upstreams >> which used to provide them aren't anymore... > It's Gentoo: "You should write your own" is the most likely answer. Actually, not at all; although I realize that's a very common misconception. Gentoo Linux is, unfortunately, often associated with the whole "gcc -O9000 -msuperfast -fwtf" wow-look-at-me crowd. It's true that some people who use Gentoo go on and rave about how many nanoseconds they were able to shave off of their boot time, or how many obscure undocumented GCC options they managed to squeeze in without a compile error. I suppose the flexible nature of Gentoo is appealing to those who like to "look cool" and show off how they can watch the compiler do its thing. However, that's not at all what the distribution is about. Gentoo is about flexibility and choice. It's got a steepish learning curve, yes, but the documentation is very good; sadly, much of it was lost a few years ago, due to a bad mishap on the community Gentoo Wiki server, apparently without any backups. Back in the day, if I wanted to learn about Samba, I'd Google "howto linux samba" and Gentoo's Wiki would usually be among the first 3 hits. Their devs take stability very seriously; it's a rolling distro, but there is still a reasonable stabilization period for each package as new versions come out, during which any open bugs may hold up the package until they're fixed. It's all about choice. In my view, Gentoo is no better or worse than Debian, Red Hat, or Ubuntu. Different species, they all make for a better ecosystem. From mfidelman at meetinghouse.net Wed Oct 22 00:10:04 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 20:10:04 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5446F2DD.7060101@lugosys.com> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> <5446E560.8080501@ninjabadger.net> <5446F2DD.7060101@lugosys.com> Message-ID: <5446F5DC.7020704@meetinghouse.net> Israel G. Lugo wrote: > On 10/21/2014 11:59 PM, Tom Hill wrote: >> On 21/10/14 23:55, Jay Ashworth wrote: >>> Ok, but how does it handle providing initscripts? I gather any upstreams >>> which used to provide them aren't anymore... >> It's Gentoo: "You should write your own" is the most likely answer. > Actually, not at all; although I realize that's a very common misconception. > > Gentoo Linux is, unfortunately, often associated with the whole "gcc > -O9000 -msuperfast -fwtf" wow-look-at-me crowd. > > It's true that some people who use Gentoo go on and rave about how many > nanoseconds they were able to shave off of their boot time, or how many > obscure undocumented GCC options they managed to squeeze in without a > compile error. I suppose the flexible nature of Gentoo is appealing to > those who like to "look cool" and show off how they can watch the > compiler do its thing. However, that's not at all what the distribution > is about. > > Gentoo is about flexibility and choice. It's got a steepish learning > curve, yes, but the documentation is very good; sadly, much of it was > lost a few years ago, due to a bad mishap on the community Gentoo Wiki > server, apparently without any backups. Back in the day, if I wanted to > learn about Samba, I'd Google "howto linux samba" and Gentoo's Wiki > would usually be among the first 3 hits. Their devs take stability very > seriously; it's a rolling distro, but there is still a reasonable > stabilization period for each package as new versions come out, during > which any open bugs may hold up the package until they're fixed. > > It's all about choice. In my view, Gentoo is no better or worse than > Debian, Red Hat, or Ubuntu. Different species, they all make for a > better ecosystem. Given the state of things, though, I'm more-and-more considering Linux from Scratch. I find that I install enough from upstream source that packaging systems (and out-of-date packages) are less and less useful. Probably easier to set up Chef or Puppet and Jenkins to just keep the overall system current - and the heck with all this distro nonsense. Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mysidia at gmail.com Wed Oct 22 00:20:12 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 21 Oct 2014 19:20:12 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <66189.1413898830@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: On Tue, Oct 21, 2014 at 8:40 AM, wrote: [snip] > It started as a replacement init system. I suspected it had jumped > the shark when it sprouted an entirely new DHCP and NTP service. And this Yikes. What's next? Built-in DNS server + LDAP/Hesiod + Kerberos + SMB/Active Directory client and server + Solitaire + Network Neighborhood functionality built into the program ? I would like to note, that I prefer Upstart as in RHEL 6. The all-in-one approach of systemd might have a place on some specialized desktop distros, but outside that niche its' IMO a terrible idea. The proper fix is probably a go back to Upstart or SysVInit and rewrite systemd, so all the pieces are separated and exist as a higher layer on top of init. Nothing wrong with having a concept such as a "systemd-desktop-program-launcher" application that the real init system runs. > was confirmed when I saw this: > > "Leading up to this has been cursor rendering support, keyboard mapping > support, screen renderer, DRM back-end, input interface, and dozens of other > commits." -- -JH From tom at ninjabadger.net Wed Oct 22 00:24:19 2014 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 22 Oct 2014 01:24:19 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5446F2DD.7060101@lugosys.com> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> <5446E560.8080501@ninjabadger.net> <5446F2DD.7060101@lugosys.com> Message-ID: <5446F933.1090005@ninjabadger.net> On 22/10/14 00:57, Israel G. Lugo wrote: > Gentoo is about flexibility and choice. It's got a steepish learning > curve, yes, but the documentation is very good; sadly, much of it was > lost a few years ago, due to a bad mishap on the community Gentoo Wiki > server, apparently without any backups. Back in the day, if I wanted to > learn about Samba, I'd Google "howto linux samba" and Gentoo's Wiki > would usually be among the first 3 hits. Their devs take stability very > seriously; it's a rolling distro, but there is still a reasonable > stabilization period for each package as new versions come out, during > which any open bugs may hold up the package until they're fixed. I certainly remember this, and miss it. The Gentoo documentation, and indeed the experience of compiling everything, was excellent. I still miss some of the tools that Gentoo had in Debian/CentOS (and the stage3 live CD is still my goto 'system rescue tool' :)) But.. I don't use it any more for anything serious. It's too much upkeep, and when the the included/maintained rc scripts for do inevitably fail to catch a corner case -- far more likely if you're using an overlay -- then you're left with little choice but to start modifying/writing your own. > It's all about choice. In my view, Gentoo is no better or worse than > Debian, Red Hat, or Ubuntu. Different species, they all make for a > better ecosystem. I was mildly unfair in the way my response was worded, but I do hold that the Gentoo way of doing things is much simpler than that of other distributions. This was, in my experience, a double-edged sword. YMMV, etc. -- Tom From jra at baylink.com Wed Oct 22 01:03:14 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 21 Oct 2014 21:03:14 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ricky Beam" > On Tue, 21 Oct 2014 18:29:44 -0400, Jay Ashworth > wrote: > > The thing that I don't understand about systemd is how it managed to > > get *EVERY SINGLE DISTRIBUTION'S RELEASE MANAGER* on board... > > It's spelled "Red Hat". Add in GNOME and debian (et. al.) is backed into a > corner. Red Hat is soo f'ing big, pretty much every project under the sun > is going to stop maintaining scripts in favor of systemd. GNOME is probably the linchpin. But it's not just RH. It's Debian, and by extension *buntu, and SuSE, and at least one other major independent parent distro that I can't think of just now... And as far as I know, it's done; SuSE packages already largely don't even include initscripts. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mpalmer at hezmatt.org Wed Oct 22 01:13:03 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 22 Oct 2014 12:13:03 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <66189.1413898830@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <20141022011256.GT16429@hezmatt.org> On Tue, Oct 21, 2014 at 09:40:30AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: > > systemd is insanity. one would have hoped that deb and others would > > know better. sigh. > > It started as a replacement init system. I suspected it had jumped > the shark when it sprouted an entirely new DHCP and NTP service. And this > was confirmed when I saw this: > > "Leading up to this has been cursor rendering support, keyboard mapping > support, screen renderer, DRM back-end, input interface, and dozens of other > commits." > > http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ > > When your init system is worrying about cursor rendering, you have truly > fallen victim to severe feature bloat. I guess Jamie Zawinski was right: > "Every program attempts to expand until it can read mail." Ooooh... /me submits a patch to systemd to provide localhost:25 and //usr/sbin/sendmail emulation... - Matt -- The real art of conversation is not only to say the right thing at the right place but to leave unsaid the wrong thing at the tempting moment. -- Dorothy Nevill From mpalmer at hezmatt.org Wed Oct 22 01:40:42 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 22 Oct 2014 12:40:42 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <20141022014042.GY16429@hezmatt.org> On Tue, Oct 21, 2014 at 07:20:12PM -0500, Jimmy Hess wrote: > On Tue, Oct 21, 2014 at 8:40 AM, wrote: > [snip] > > It started as a replacement init system. I suspected it had jumped > > the shark when it sprouted an entirely new DHCP and NTP service. And this > > Yikes. What's next? Built-in DNS server + LDAP/Hesiod + Kerberos + > SMB/Active Directory client and server + Solitaire + Network > Neighborhood functionality built into the program ? You missed "font renderer". https://technet.microsoft.com/library/security/ms14-058 - Matt -- A friend is someone you can call to help you move. A best friend is someone you can call to help you move a body. From mfidelman at meetinghouse.net Wed Oct 22 02:11:24 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 21 Oct 2014 22:11:24 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022011256.GT16429@hezmatt.org> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <20141022011256.GT16429@hezmatt.org> Message-ID: <5447124C.1080702@meetinghouse.net> On Tue, Oct 21, 2014 at 09:40:30AM -0400, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: >>> systemd is insanity. one would have hoped that deb and others would >>> know better. sigh. >> It started as a replacement init system. I suspected it had jumped >> the shark when it sprouted an entirely new DHCP and NTP service. And this >> was confirmed when I saw this: >> >> "Leading up to this has been cursor rendering support, keyboard mapping >> support, screen renderer, DRM back-end, input interface, and dozens of other >> commits." >> >> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ >> >> When your init system is worrying about cursor rendering, you have truly >> fallen victim to severe feature bloat. I guess Jamie Zawinski was right: >> "Every program attempts to expand until it can read mail." So which comes first: - systemd-emacs or - emacs-systemd-mode ? :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From larrysheldon at cox.net Wed Oct 22 03:29:33 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 21 Oct 2014 22:29:33 -0500 Subject: Jared Mauch Message-ID: <5447249D.5030301@cox.net> I don't remember seeing mention of this here: https://www.youtube.com/watch?v=69-qhoS9sSw h/t Suresh Ramasubramian on Facebook. (I didn't copy and paste any names--hope I got them right.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From nccariaga at stluke.com.ph Wed Oct 22 04:15:42 2014 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 22 Oct 2014 12:15:42 +0800 Subject: ISP Shaping Hardware In-Reply-To: References: Message-ID: <54472F6E.4050204@stluke.com.ph> I haven't heard of a Virtual Appliance for Allot. We have used the appliance for quite some time already but I am looking forward in replacing it (as soon as possible) due to the poor support in our region. -nathan On 10/21/2014 5:34 AM, Skeeve Stevens wrote: > What I'd really love is a vAppliance. Some of these hardware solutions are > VERY expensive for offering only an average solution. I'd also rather not > rely on their hardware, but servers with VMware (or whatever) that we can > design our own redundancy. > > Does anyone know if Allot does a Virtual Appliance? > > I've also heard that pfSense is an interesting option... That could easily > be virtualised I would assume. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > On 20 October 2014 22:31, Nurul Islam Roman wrote: > >> Used following two product to shape traffic on packet level (L3). Had no >> issue with several thousand customer. >> >> Allot >> http://www.allot.com/netenforcer.html >> >> ET >> http://www.etinc.com/ >> >> Found "Allot" is very popular for satellite based Internet specially in >> south pacific island countries. >> >> -R >> >> >> On 20/10/14 2:55 PM, "Skeeve Stevens" >> wrote: >> >>> Hey all, >>> >>> Just wondering what/if people are using any shaping hardware/appliances >>> these days, and if so, what. >>> >>> I have a client which has thousands of customers on Satellite and needs to >>> restrict some users who are doing a lot. >>> >>> So I wanted to see what the current popular equipment out there is. >>> >>> ...Skeeve >>> >>> *Skeeve Stevens - *eintellego Networks Pty Ltd >>> skeeve at eintellegonetworks.com ; www.eintellegonetworks.com >>> >>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >>> >>> facebook.com/eintellegonetworks ; >>> linkedin.com/in/skeeve >>> >>> experts360: https://expert360.com/profile/d54a9 >>> >>> twitter.com/theispguy ; blog: www.theispguy.com >>> >>> >>> The Experts Who The Experts Call >>> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering From itg at itechgeek.com Wed Oct 22 05:25:46 2014 From: itg at itechgeek.com (ITechGeek) Date: Wed, 22 Oct 2014 01:25:46 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> Message-ID: Instead of multiple govs trying to use .gov or .mil, the best idea would be to collapse .gov under .gov.us and .mil under .mil.us (Much like how other countries already work). I don't see that happening as long as the US gov has a say in the matter. I think .su will be decommissioned long before .gov or .mil are. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Tue, Oct 21, 2014 at 2:17 PM, David Conrad wrote: > On Oct 21, 2014, at 10:33 AM, Sandra Murphy wrote: > >> Folks outside of the US have issues with the US government having a > role in the administration of the root, even if that role is to ensure > ICANN does screw the pooch. > > > > I'm thinking there's a "not" missing here. > > For the numerous people who have suggested similar, both publicly and > privately: yes, I did accidentally leave out a teensy little word. I > honestly wasn't making a comment about my current (perhaps until my boss > reads the post) employer. Really. No, really. > > That'll teach me to post pre-coffee. > > Regards, > -drc > > From larrysheldon at cox.net Wed Oct 22 05:43:38 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 22 Oct 2014 00:43:38 -0500 Subject: Jared Mauch (Good News!) In-Reply-To: <65aW1p00V0QKCTq015aYPb> References: <5447249D.5030301@cox.net> <65aW1p00V0QKCTq015aYPb> Message-ID: <5447440A.5070005@cox.net> It has been brought to my attention that once again I have done a poor job of developing a good Subject: line*. The clip contains good news and I thought a possibly welcome review of the work involved. > The subject and content made me think this was a video on the > horrible way he had died or something. *It doesn't look that hard to do! -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From brunner at nic-naa.net Wed Oct 22 05:43:05 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 21 Oct 2014 22:43:05 -0700 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> Message-ID: <544743E9.4020602@nic-naa.net> it was at ietf-9, while jon and i were discussing the {features|flaws} of iso3166-1, that another contributor approached us and ... spoke to the unfairness, as argued by that contributor, of the armed forces of the united kingdom being excluded from the use (as registrants) of the .mil namespace. i suggest the question is asked and answered, and as i offered slightly obliquely earlier, the policy of an agency of government committed to commercial deregulation (since the second clinton administration), in particular use of .us, may not be the policy of the government in general, nor the policy of an agency of government otherwise tasked, e.g., the department of defense. On 10/21/14 10:25 PM, ITechGeek wrote: > Instead of multiple govs trying to use .gov or .mil, the best idea would be > to collapse .gov under .gov.us and .mil under .mil.us could we now put a good night kiss on the forehead of this sleepy child and let him or her dream of candy and ponies? -e From george.herbert at gmail.com Wed Oct 22 06:16:33 2014 From: george.herbert at gmail.com (George Herbert) Date: Tue, 21 Oct 2014 23:16:33 -0700 Subject: Linux: concerns over systemd [OT] In-Reply-To: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> Message-ID: <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> > On Oct 21, 2014, at 6:03 PM, Jay Ashworth wrote: > > GNOME is probably the linchpin. > > But it's not just RH. It's Debian, and by extension *buntu, and SuSE, and > at least one other major independent parent distro that I can't think of > just now... > > And as far as I know, it's done; SuSE packages already largely don't even > include initscripts. Enough to make a grown man fork RHEL (or, CentOS). George William Herbert Sent from my iPhone From oscar.vives at gmail.com Wed Oct 22 08:04:37 2014 From: oscar.vives at gmail.com (Tei) Date: Wed, 22 Oct 2014 10:04:37 +0200 Subject: Why is .gov only for US government agencies? In-Reply-To: <544743E9.4020602@nic-naa.net> References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> <544743E9.4020602@nic-naa.net> Message-ID: (very unimportant contribution, please ignore) any change to this things, must be done in the benefit of future users, making the internet a less weird place, with less exceptions everyone else have already learned a .edu domain is probably a USA university, and some .mil domain is the usa military. ((unfunny joke follow, you can stop reading here)) http://www.usma.edu => usma.edu.mil.us -- -- ℱin del ℳensaje. From mfidelman at meetinghouse.net Wed Oct 22 09:41:38 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 05:41:38 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> Message-ID: <54477BD2.10905@meetinghouse.net> George Herbert wrote: > > > >> On Oct 21, 2014, at 6:03 PM, Jay Ashworth wrote: >> >> GNOME is probably the linchpin. >> >> But it's not just RH. It's Debian, and by extension *buntu, and SuSE, and >> at least one other major independent parent distro that I can't think of >> just now... >> >> And as far as I know, it's done; SuSE packages already largely don't even >> include initscripts. > Enough to make a grown man fork RHEL (or, CentOS). > > > Which leads me to ask - those of you running server farms - what distros are popular these days, for server-side operations? We've been running Debian like forever (by way of Solaris and redhat) - but this systemd thing is making me rethink things. Seems like an awful lot of folks are now designing for the desktop, and it might be time to migrate to a BSD or Solaris derivative. What are others doing? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tom at ninjabadger.net Wed Oct 22 10:09:51 2014 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 22 Oct 2014 11:09:51 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54477BD2.10905@meetinghouse.net> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> Message-ID: <5447826F.9080000@ninjabadger.net> On 22/10/14 10:41, Miles Fidelman wrote: > Which leads me to ask - those of you running server farms - what distros > are popular these days, for server-side operations? We've been running > Debian like forever (by way of Solaris and redhat) - but this systemd > thing is making me rethink things. Seems like an awful lot of folks are > now designing for the desktop, and it might be time to migrate to a BSD > or Solaris derivative. What are others doing? Not making rash decisions. Debian and CentOS are still the 'asked for' distributions of Linux. Once in a blue moon, someone asks about something else. Those that care are outnumbered greatly by those that just want a known platform to develop upon. (The irony of this is not lost on me). I'd take systemd over ditching apt/yum in a mad panic. And I'm certainly no fan of systemd myself. -- Tom From nanog at jack.fr.eu.org Wed Oct 22 10:34:17 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 22 Oct 2014 12:34:17 +0200 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5447826F.9080000@ninjabadger.net> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> Message-ID: <54478829.8080700@jack.fr.eu.org> Before leaving Debian, things to think: - will systemd be officialy the only system available ? - if so, won't we get a way to bypass that ? I'm not gonna throw Debian away due to such a mess, without fighting hard, and I think you should do the same: talk, patch if needed, show you're here If all good people who laugh insanely about systemd leave Debian alone, who's left ? gnome-people ? systemd-fanatics (heretics?) ? On 22/10/2014 12:09, Tom Hill wrote: > On 22/10/14 10:41, Miles Fidelman wrote: >> Which leads me to ask - those of you running server farms - what distros >> are popular these days, for server-side operations? We've been running >> Debian like forever (by way of Solaris and redhat) - but this systemd >> thing is making me rethink things. Seems like an awful lot of folks are >> now designing for the desktop, and it might be time to migrate to a BSD >> or Solaris derivative. What are others doing? > > Not making rash decisions. > > Debian and CentOS are still the 'asked for' distributions of Linux. Once > in a blue moon, someone asks about something else. > > Those that care are outnumbered greatly by those that just want a known > platform to develop upon. (The irony of this is not lost on me). > > I'd take systemd over ditching apt/yum in a mad panic. And I'm certainly > no fan of systemd myself. > From elmi at 4ever.de Wed Oct 22 10:39:22 2014 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 22 Oct 2014 12:39:22 +0200 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54478829.8080700@jack.fr.eu.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <20141022103922.GD18888@h.detebe.org> nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) wrote: > I'm not gonna throw Debian away due to such a mess, without fighting > hard, and I think you should do the same: talk, patch if needed, show > you're here ...and sit it out with wheezy-LTS... Elmar. From randy at psg.com Wed Oct 22 10:44:34 2014 From: randy at psg.com (Randy Bush) Date: Wed, 22 Oct 2014 19:44:34 +0900 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54477BD2.10905@meetinghouse.net> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> Message-ID: > Which leads me to ask - those of you running server farms - what > distros are popular these days, for server-side operations? been running bsd forever. but moving to debian and ganeti, as bsd does not host virtualization. would love it if debian ditched this systemd monstrosity and provided solid zfs. randy From mansaxel at besserwisser.org Wed Oct 22 10:46:56 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 22 Oct 2014 12:46:56 +0200 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5446C5A1.3040801@nic-naa.net> References: <5445AD63.7090400@lugosys.com> <5446C5A1.3040801@nic-naa.net> Message-ID: <20141022104656.GA5026@besserwisser.org> Subject: Re: Linux: concerns over systemd adoption and Debian's decision to switch Date: Tue, Oct 21, 2014 at 01:44:17PM -0700 Quoting Eric Brunner-Williams (brunner at nic-naa.net): > >systemd is insanity. > > see also smit. (assumption, we're talking about AIX smit here) smit is transparent, comprehensible and automatable, not to mention bypass-able. My wife, who is running an impressive AIX farm at her place of work, tells me that (and I've done it myself) F4 is the key to escape. systemd is hellspawn crap compared to this. I'm really concerned because I run complicated process control software on Linux and this software is shipped by Vendors who believe in "if there is a support contract for the OS, all is well" fairy tales. This leaves you having to buy DeadRat licenses, unless you can convince them that Centos is functionally equivalent. Time to ask for BSD ports, I think. Linux will be unusable very soon. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 WHOA!! Ken and Barbie are having TOO MUCH FUN!! It must be the NEGATIVE IONS!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jgreco at ns.sol.net Wed Oct 22 10:52:11 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Oct 2014 05:52:11 -0500 (CDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <201410221052.s9MAqBZt096450@aurora.sol.net> > > Which leads me to ask - those of you running server farms - what > > distros are popular these days, for server-side operations? > > been running bsd forever. but moving to debian and ganeti, as bsd does > not host virtualization. Simply not true; http://bhyve.org/ It is a bit immature compared to Xen+Ganeti or something like that. > would love it if debian ditched this systemd > monstrosity and provided solid zfs. ... 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 md1clv at md1clv.com Wed Oct 22 11:00:52 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Wed, 22 Oct 2014 12:00:52 +0100 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54478829.8080700@jack.fr.eu.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: On 22 October 2014 11:34, wrote: > Before leaving Debian, things to think: > - will systemd be officialy the only system available ? > - if so, won't we get a way to bypass that ? > And one other thought... is it really that bad? Personally I like it a lot better than sysV plus inittab plus daemontools. Dan From randy at psg.com Wed Oct 22 11:01:54 2014 From: randy at psg.com (Randy Bush) Date: Wed, 22 Oct 2014 20:01:54 +0900 Subject: Linux: concerns over systemd [OT] In-Reply-To: <201410221052.s9MAqBZt096450@aurora.sol.net> References: <201410221052.s9MAqBZt096450@aurora.sol.net> Message-ID: >>> Which leads me to ask - those of you running server farms - what >>> distros are popular these days, for server-side operations? >> been running bsd forever. but moving to debian and ganeti, as bsd >> does not host virtualization. > Simply not true; http://bhyve.org/ > It is a bit immature compared to Xen+Ganeti or something like that. apologies. i thought we were talking about production systems. my mistake. randy From rsk at gsp.org Wed Oct 22 11:04:27 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 22 Oct 2014 07:04:27 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54469515.5020104@lugosys.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> Message-ID: <20141022110427.GA4921@gsp.org> On Tue, Oct 21, 2014 at 06:17:09PM +0100, Israel G. Lugo wrote: > The binary logs for example worry me, especially corruption issues: As they should. Binary logs occasionally make sense in environments where the amount of information to be logged is huge and the rate at which it accumulates is very high -- but those situations are few and far between, and certainly not in play in the normal operation of a 'nix system. For everything else, text -- which is and has been the lingua franca of 'nix systems since they've existed -- is perfectly adequate, and strongly preferable. I've seen similar tactical mistakes when developers insist that information *must* be stored in a relational database -- even though plain old ordinary text files are perfectly adequate for the task, are easier to debug, are easier to fix, and easier to maintain. There is an unfortunate tendency among many developers to attempt to wring the very last bit of performance out of systems and not to take into consideration that the scarcest and most expensive resource is the system administrator. Saving a few microseconds or a handful of bytes here and there is a horribly bad idea if it chews up an extra hour or week of SA time. ---rsk From jgreco at ns.sol.net Wed Oct 22 11:12:29 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Oct 2014 06:12:29 -0500 (CDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <201410221112.s9MBCTHG096890@aurora.sol.net> > >>> Which leads me to ask - those of you running server farms - what > >>> distros are popular these days, for server-side operations? > >> been running bsd forever. but moving to debian and ganeti, as bsd > >> does not host virtualization. > > Simply not true; http://bhyve.org/ > > It is a bit immature compared to Xen+Ganeti or something like that. > > apologies. i thought we were talking about production systems. my > mistake. Oh, c'mon Randy, you've been around long enough to know how this all works. You can't honestly tell me that VMware ESX was born handling production loads. You can't honestly tell me that Xen was born handling production loads. All hypervisor technologies were new at one point in their life cycle, and most were also catastrofails at one point in their life cycle. The fact that bhyve is new means it's more immature, but people are certainly trying noncricitical production loads on it. Y'know, the same way they did years ago with ESX. No one's saying you have to trust it with your production workloads, but it's pretty unfair to characterize BSD as "not host(ing) virtualization" when so much effort has been put into that very issue, specifically so that we could gain the advantages of a BSD hypervisor that supported ZFS natively... ... 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 mpalmer at hezmatt.org Wed Oct 22 11:21:04 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 22 Oct 2014 22:21:04 +1100 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <20141022112104.GE16429@hezmatt.org> On Wed, Oct 22, 2014 at 12:00:52PM +0100, Daniel Ankers wrote: > On 22 October 2014 11:34, wrote: > > Before leaving Debian, things to think: > > - will systemd be officialy the only system available ? > > - if so, won't we get a way to bypass that ? > > And one other thought... is it really that bad? > > Personally I like it a lot better than sysV plus inittab plus daemontools. When it was init+daemontools, I could hold my nose over the binary logging and consider using it. Now it's taking over cron and all manner of other things, there's no way in hell I'm letting it onto my systems. As to the issue of "will it only be systemd", the problem is that as the officially-blessed option, that's the one that'll get the universal support, so if you want to run something else, some things will mysteriously not work, and package maintainers won't care nearly as much. Bypassing systemd is a whole hell of a lot harder than switching out sysvinit for something else, because systemd does so many things, and many other things are being modified to absolutely depend on things that only systemd provides -- GNOME's the big one, but docker is closely tied to systemd too, I believe, I think udev needs systemd now (or has it been incorporated into systemd? I can't keep all this straight) and I'm pretty sure I've heard of other things deprecating non-systemd ways of doing things. The *really* damaging part of it, though, is that as systemd grows to overshadow the things it re-implements (udev, dbus, etc) it starves the alternatives of light and they quickly fall behind and are no longer viable as ways to avoid systemd. That isn't systemd's fault, per se, but it does make it much harder over time to avoid getting caught in the gaping maw. - Matt From nanog at jack.fr.eu.org Wed Oct 22 11:23:02 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 22 Oct 2014 13:23:02 +0200 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <54479396.9000206@jack.fr.eu.org> When it's working, no doupt, I'll be fine I don't care (or just a few) about when it's working. The point is: what about it's failure ? On the ethical point of view, systemd is killed anyway On 22/10/2014 13:00, Daniel Ankers wrote: > On 22 October 2014 11:34, > wrote: > > Before leaving Debian, things to think: > - will systemd be officialy the only system available ? > - if so, won't we get a way to bypass that ? > > > And one other thought... is it really that bad? > > Personally I like it a lot better than sysV plus inittab plus daemontools. > > Dan From rwebb at ropeguru.com Wed Oct 22 11:27:07 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 22 Oct 2014 07:27:07 -0400 Subject: Jared Mauch In-Reply-To: <5447249D.5030301@cox.net> References: <5447249D.5030301@cox.net> Message-ID: Congrats Jared!!! On Tue, 21 Oct 2014 22:29:33 -0500 Larry Sheldon wrote: > I don't remember seeing mention of this here: > > https://www.youtube.com/watch?v=69-qhoS9sSw > > h/t Suresh Ramasubramian on Facebook. > > (I didn't copy and paste any names--hope I got them right.) > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > Quis custodiet ipsos custodes From jamie.s.bowden at raytheon.com Wed Oct 22 11:36:55 2014 From: jamie.s.bowden at raytheon.com (Jamie Bowden) Date: Wed, 22 Oct 2014 11:36:55 +0000 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> Message-ID: <5EA9A87201F2AB42BFD9B954797F19BE0338B21B@PRA-IAD-MAIL.pra.ray.com> > From: Bryan Tong > The final fact is that bash itself is a dirty language that developers hate > and system administrators love. Excuse me? I've been administering systems for over twenty years now and I can't say that I've ever even once chosen to use bash over any alternative; no matter how much that alternative might suck, bash sucks more. Your Linux addicts who've never used another flavor of Unix may be addicted to bash, but there's no helping some people. Jamie From mysidia at gmail.com Wed Oct 22 12:07:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 22 Oct 2014 07:07:22 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <201410221112.s9MBCTHG096890@aurora.sol.net> References: <201410221112.s9MBCTHG096890@aurora.sol.net> Message-ID: On Wed, Oct 22, 2014 at 6:12 AM, Joe Greco wrote: > when so much effort has been put into that very issue, specifically so > that we could gain the advantages of a BSD hypervisor that supported > ZFS natively... [snip] If you want native ZFS support, then Solaris x86-64+Zones+KVM or SmartOS. Now Solaris/Illumos' process supervision and fault management systems, SMF and FMA are pretty complex, but they aren't stuffing 1000 random tasks into the init program. ^_^ > > ... JG -- -JH From Valdis.Kletnieks at vt.edu Wed Oct 22 12:15:58 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 22 Oct 2014 08:15:58 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: Your message of "Wed, 22 Oct 2014 12:34:17 +0200." <54478829.8080700@jack.fr.eu.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <40315.1413980158@turing-police.cc.vt.edu> On Wed, 22 Oct 2014 12:34:17 +0200, nanog at jack.fr.eu.org said: > Before leaving Debian, things to think: > - will systemd be officialy the only system available ? > - if so, won't we get a way to bypass that ? Somebody already forked systemd at a point before it completely lost the plot. http://uselessd.darknedgy.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From list at satchell.net Wed Oct 22 12:43:29 2014 From: list at satchell.net (Stephen Satchell) Date: Wed, 22 Oct 2014 05:43:29 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022110427.GA4921@gsp.org> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <20141022110427.GA4921@gsp.org> Message-ID: <5447A671.6060005@satchell.net> On 10/22/2014 04:04 AM, Rich Kulawiec wrote: > I've seen similar tactical mistakes when developers insist that > information *must* be stored in a relational database -- even though > plain old ordinary text files are perfectly adequate for the task, > are easier to debug, are easier to fix, and easier to maintain. Right on, bro. I'm in the middle of a "system" where the architect insists on just that. Never mind that I brought the relational database server to its knees (even flat on its back) because of the sheer number of processes I'm running, and the load on the engine that causes. My *ONLY* option was to replicate the information in the database and store it in files on the servers I'm running on -- semi-permanent data on the hard drives, working data in a RAM disk system. "But updates don't happen instantly, we have to wait for your replication daemon to run!" Yep. Amazing how that makes the entire system considerably more stable when you don't change horses mid-flight. Not to mention the considerable reduction in inter-server network traffic. How did this discussion get into NANOG? :) From mfidelman at meetinghouse.net Wed Oct 22 13:59:07 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 09:59:07 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54478829.8080700@jack.fr.eu.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <5447B82B.1000502@meetinghouse.net> nanog at jack.fr.eu.org wrote: > Before leaving Debian, things to think: > - will systemd be officialy the only system available ? > - if so, won't we get a way to bypass that ? officially, there will be support for multiple init systems; in practice, the installer doesn't provide an option, and trying to remove systemd seems to drag one into dependency hell > > I'm not gonna throw Debian away due to such a mess, without fighting > hard, and I think you should do the same: talk, patch if needed, show > you're here unfortunately, the fight is rather ugly, and seemingly fruitless (have you been on debian-user, debian-devel, or debian-vote lately?) - sigh... this discussion, if a bit OT for nanog, is a breath of fresh air - PLEASE weigh in on the side of goodness and light Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From andre-nanog at tomt.net Wed Oct 22 14:17:32 2014 From: andre-nanog at tomt.net (Andre Tomt) Date: Wed, 22 Oct 2014 16:17:32 +0200 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022014042.GY16429@hezmatt.org> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <20141022014042.GY16429@hezmatt.org> Message-ID: <5447BC7C.6080106@tomt.net> On 22. okt. 2014 03:40, Matt Palmer wrote: > On Tue, Oct 21, 2014 at 07:20:12PM -0500, Jimmy Hess wrote: >> Yikes. What's next? Built-in DNS server + LDAP/Hesiod + Kerberos + >> SMB/Active Directory client and server + Solitaire + Network >> Neighborhood functionality built into the program ? > > You missed "font renderer". > https://technet.microsoft.com/library/security/ms14-058 I am not convinced having font rendering *IN THE KERNEL* is much better for security.. and I doubt they put it in pid 1. Now, should consoled, the new ntp and dhcp services have been stuffed into the systemd tarball.. I dont know. From jeff at ocjtech.us Wed Oct 22 16:01:33 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 11:01:33 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo wrote: > > Not intending to start a flame war here. Bull. If you've been around the FOSS community even for a short while, you'd know that systemd has become a religious topic akin to Emacs vs. Vi "discussions" etc. I realize that many of the people that read the NANOG list also use Linux systems, but that's not what I come here for. Please, take the systemd discussions to the mailing lists for your distribution of choice. -- Jeff Ollie From mfidelman at meetinghouse.net Wed Oct 22 16:12:07 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 12:12:07 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <5447D757.8010307@meetinghouse.net> Jeffrey Ollie wrote: > On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo wrote: >> Not intending to start a flame war here. > Bull. If you've been around the FOSS community even for a short > while, you'd know that systemd has become a religious topic akin to > Emacs vs. Vi "discussions" etc. I realize that many of the people > that read the NANOG list also use Linux systems, but that's not what I > come here for. > > Please, take the systemd discussions to the mailing lists for your > distribution of choice. > Seems to me, this has been a very rational discussion, confined to one very identifiable thread, containing what at least this reader finds very useful (operational impacts of systemd in server-side environments, and what alternatives people are looking at). If you're not interested, you have a delete key. Please use it, and don't turn this into a flame war. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jeff at ocjtech.us Wed Oct 22 16:30:57 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 11:30:57 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447D757.8010307@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: On Wed, Oct 22, 2014 at 11:12 AM, Miles Fidelman wrote: > > Seems to me, this has been a very rational discussion, Hardly. The discussion so far has been weighted very heavily on the side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way it was and we liked it!". The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. There's no way to argue rationally with that. > confined to one very identifiable thread, Thank goodness! > containing what at least this reader finds very useful > (operational impacts of systemd in server-side environments, and what > alternatives people are looking at). Just because it's useful, doesn't mean that it isn't off-topic for NANOG. At least until Cisco starts using systemd as pid 1 in IOS XE I suppose... > If you're not interested, you have a delete key. Please use it, and don't > turn this into a flame war. Sure, I have a delete key, but it'd still be better if people moved this discussion somewhere more appropriate. -- Jeff Ollie From israel.lugo at lugosys.com Wed Oct 22 16:37:33 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Wed, 22 Oct 2014 17:37:33 +0100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447D757.8010307@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <5447DD4D.1000809@lugosys.com> On 22-10-2014 17:12, Miles Fidelman wrote: > Seems to me, this has been a very rational discussion, confined to one > very identifiable thread, containing what at least this reader finds > very useful (operational impacts of systemd in server-side > environments, and what alternatives people are looking at). > > If you're not interested, you have a delete key. Please use it, and > don't turn this into a flame war. Agreed. I've found this thread to be very interesting, and appreciate listening to everyone's opinions on the matter. It does have a meaningful operational impact, and from what I've read it seems we should at least think about how to deal with this. From jlarsen at richweb.com Wed Oct 22 16:43:53 2014 From: jlarsen at richweb.com (C. Jon Larsen) Date: Wed, 22 Oct 2014 12:43:53 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: > Hardly. The discussion so far has been weighted very heavily on the > side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way > it was and we liked it!". > > The people that like systemd (like myself) have wisely learned that > the people that hate systemd, hate it mostly because it's different > from what came before and don't want to change. There's no way to > argue rationally with that. Incorrect assumption. systemd is a massive security hole waiting to happen and it does not follow the unix philosophy of done 1 thing and do it well/correct. Its basically ignoring 40 years of best practices. Thats why folks that have been there, done that, dont want any part of it. Not because its new, but because its a flawed concept. You are free to use it, but it would be a poor choice for system that has hopes of being secure. > -- > Jeff Ollie > > From israel.lugo at lugosys.com Wed Oct 22 16:46:22 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Wed, 22 Oct 2014 17:46:22 +0100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <5447DF5E.6090402@lugosys.com> On 22-10-2014 17:30, Jeffrey Ollie wrote: > Hardly. The discussion so far has been weighted very heavily on the > side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way > it was and we liked it!". The people that like systemd (like myself) > have wisely learned that the people that hate systemd, hate it mostly > because it's different from what came before and don't want to change. > There's no way to argue rationally with that. Not everyone "hates it". I for one would be very much interested in listening to what you have to say about systemd, if you find it to be a positive change. How is it better, and how you look at some of the concerns raised in this thread. At least for me, a balancing opinion would be welcome. From asullivan at dyn.com Wed Oct 22 17:08:43 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 22 Oct 2014 13:08:43 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <20141022170842.GB37494@dyn.com> On Wed, Oct 22, 2014 at 12:43:53PM -0400, C. Jon Larsen wrote: > Incorrect assumption. systemd is a massive security hole waiting to happen > and it does not follow the unix philosophy of done 1 thing and do it > well/correct. It does seem to me that this angle, at least, is on-topic for NANOG, and I hope someone has suggestions for how to mitigate it. It seems that we've had two or, arguably, three recent examples (heartbleed, shellshock, arguably poodle) of complicated code that too few people understood and that led to widespread, late-night-inducing emergency action once a serious vulnerability was discovered. Surely that direction of development in a process that runs as PID 1 is something that has significant follow-on effects for network security. But I have no clue what one can do about it. For many years, I liked to keep some Linux and some BSD systems around, because it seemed to me that the different styles tended to encourage diversity and that was a good thing. But management of BSD systems -- particularly the nonsense of rebuilding things from source all the time -- started to look mighty onerous compared to apt-get update; apt-get upgrade. Others apparently agreed, and now there are enough things that work well on Linux but not as well (or not at all) on BSD that the diversity argument isn't as strong. (Also, of course, certain kinds of things, like some kinds of database replication, don't work well across platforms, so there's another reason to converge on a single system.) Debian was always the Linux platform that seemed most insistent on having more than one way to do it, but in recent years that philosophy has made it more work to use than the alternatives; and the alternatives have often gotten good enough that one doesn't care (Ubuntu is the obvious example here). So, now we have an encroaching monoculture, and no real option to do anything about it. Maybe this is just the way the Internet is, now. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From george.herbert at gmail.com Wed Oct 22 17:35:22 2014 From: george.herbert at gmail.com (George Herbert) Date: Wed, 22 Oct 2014 10:35:22 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <86B76303-7D53-4017-BF2C-1FD095E73AC4@gmail.com> > On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie wrote: > > The people that like systemd (like myself) have wisely learned that > the people that hate systemd, hate it mostly because it's different > from what came before and don't want to change. There's no way to > argue rationally with that. I think you are monumentally misreading the situation. A) Change is the constant in IT. Staying relevant and employable has put me through five or more generational shifts in enterprise OS, plus diversions to Mach, Plan 9, MacOS, etc. Change is normal. B) Systemd and the Solaris SMF that it conceptually followed have a number of technical flaws, ranging from obscure interfaces (sometimes requiring source code to understand) to lack of human readable configs to (at least with SMF, and as far as I can tell systemd) a lack of ability to even print/dump out the current dependencies and ordering tree. C) In both systemd and SMF a tremendous unpreparedness of training and documentation accompanied rollout. These were not reasonably enterprise ready at launch, or now. D) The architectural case that the services adopted in systemd over time belong there or are safe there is not proven, and not that I see well argued or documented. Conglomerated services are at least to be eyed skeptically. I did not closely follow systemd's development but it is evident from a distance that operator feedback in the community and to Sun regarding SMF flaws was somehow missed in systemd's development as they did the same wrong things. A change this big deserves architectural clarity and justification. We get snide comments about change being good and core developers Linus evidently feels are unsafe. George William Herbert Sent from my iPhone From corbe at corbe.net Wed Oct 22 17:35:26 2014 From: corbe at corbe.net (Daniel Corbe) Date: Wed, 22 Oct 2014 13:35:26 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022170842.GB37494@dyn.com> (Andrew Sullivan's message of "Wed, 22 Oct 2014 13:08:43 -0400") References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022170842.GB37494@dyn.com> Message-ID: Andrew Sullivan writes: > On Wed, Oct 22, 2014 at 12:43:53PM -0400, C. Jon Larsen wrote: > >> Incorrect assumption. systemd is a massive security hole waiting to happen >> and it does not follow the unix philosophy of done 1 thing and do it >> well/correct. > > But I have no clue what one can do about it. For many years, I liked > to keep some Linux and some BSD systems around, because it seemed to > me that the different styles tended to encourage diversity and that > was a good thing. But management of BSD systems -- particularly the > nonsense of rebuilding things from source all the time -- started to > look mighty onerous compared to apt-get update; apt-get upgrade. > Others apparently agreed, and now there are enough things that work > well on Linux but not as well (or not at all) on BSD that the > diversity argument isn't as strong. (Also, of course, certain kinds > of things, like some kinds of database replication, don't work well > across platforms, so there's another reason to converge on a single > system.) Debian was always the Linux platform that seemed most > insistent on having more than one way to do it, but in recent years > that philosophy has made it more work to use than the alternatives; > and the alternatives have often gotten good enough that one doesn't > care (Ubuntu is the obvious example here). > > So, now we have an encroaching monoculture, and no real option to do > anything about it. Maybe this is just the way the Internet is, now. > > A Not to get even further off topic here but when was the last time you maintained a BSD system? FreeBSD (at least) adopted binary package management as its preferred interface to ports through pkg-ng somewhere in the 9-RELEASE cycle. As long as you don't need exotic compile-time options you should be good to go. Which is in contrast to the Linux package management paradigm where you basically enable everything at compile time. If you do need to compile something by source though you still have that option. This systemd debacle is an excellent reason to look into stuff that isn't Linux. The Linux camp all too often become victims of "not invented here" and "because we can" is not a good enough reason to replace something that has worked just fine for 30 or 40 some-odd years. From jeff at ocjtech.us Wed Oct 22 17:41:53 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 12:41:53 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: On Wed, Oct 22, 2014 at 11:43 AM, C. Jon Larsen wrote: > >> Hardly. The discussion so far has been weighted very heavily on the >> side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way >> it was and we liked it!". >> >> The people that like systemd (like myself) have wisely learned that >> the people that hate systemd, hate it mostly because it's different >> from what came before and don't want to change. There's no way to >> argue rationally with that. > > Incorrect assumption. systemd is a massive security hole waiting to happen The same can be said for any software. Shellshock anyone? How many security issues remain in bash? One of the reasons systemd was first written was to get rid of the the tangle of shell scripts that are used to start up a system using sysvinit. > and it does not follow the unix philosophy of done 1 thing and do it > well/correct. Its basically ignoring 40 years of best practices. Thats why > folks that have been there, done that, dont want any part of it. Not because > its new, but because its a flawed concept. I was going to write a longer response here, but this: http://lwn.net/Articles/576078/ sums up my thoughts on the "unix philosophy". It's not the be-all-end-all that you make it out to be. Again, this sounds a lot like "Grumpy Old Man" complaining. > You are free to use it, but it would be a poor choice for system that has > hopes of being secure. I would disagree, especially since systemd makes it practical to use many of the capabilities of the Linux kernel that can improve security, like filesystem namespaces, cgroups, etc. -- Jeff Ollie From bzs at world.std.com Wed Oct 22 18:15:58 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 14:15:58 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <20141021201019.GE36267@dyn.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> Message-ID: <21575.62558.449089.867918@world.std.com> I'm reminded of the remark often attributed to DEC CEO Ken Olson, roughly: With VMS (their big complex OS) it might take hours searching through manuals to find a feature you need while with Unix you can determine in seconds that it is not available. On October 21, 2014 at 16:10 asullivan at dyn.com (Andrew Sullivan) wrote: > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: > > But > > for example some of my servers boot in seconds. > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS > Handbook_, available at > http://www.art.net/~hopkins/Don/unix-haters/preface.html. Apparently, > things really are going to get a lot worse before they get worse. > > Best regards, > > A > > -- > Andrew Sullivan > Dyn, Inc. > asullivan at dyn.com > v: +1 603 663 0448 -- -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 jeff at ocjtech.us Wed Oct 22 18:22:12 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 13:22:12 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <86B76303-7D53-4017-BF2C-1FD095E73AC4@gmail.com> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <86B76303-7D53-4017-BF2C-1FD095E73AC4@gmail.com> Message-ID: On Wed, Oct 22, 2014 at 12:35 PM, George Herbert wrote: > > > > >> On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie wrote: >> >> The people that like systemd (like myself) have wisely learned that >> the people that hate systemd, hate it mostly because it's different >> from what came before and don't want to change. There's no way to >> argue rationally with that. > > I think you are monumentally misreading the situation. > > A) Change is the constant in IT. Staying relevant and employable has put me through five or more generational shifts in enterprise OS, plus diversions to Mach, Plan 9, MacOS, etc. Change is normal. I agree with you about change, but there are a number of people that vocally resist any kind of change, no matter what. There's little that can change their mind other than time. It's a useful skill to be able to recognize these people and not to let them get you down. > B) Systemd and the Solaris SMF that it conceptually followed have a number of technical flaws, ranging from obscure interfaces (sometimes requiring source code to understand) to lack of human readable configs to (at least with SMF, and as far as I can tell systemd) a lack of ability to even print/dump out the current dependencies and ordering tree. I have no experience with Solaris SMF so I can't comment on it specifically, but in my opinion systemd: 1) has excellent documentation, especially when you compare it to other open source documentation. 2) What's more readable than .ini files? They even avoided the temptation to use XML. I can't tell you how much time I've wasted reading shell script spaghetti trying to figure out exactly how a service is started up. Services implemented in Java and Ruby seem to be especially bad at that. 3) systemctl list-dependencies, although since service start-up in systemd is highly dynamic it's difficult to predict what order services will start up. > C) In both systemd and SMF a tremendous unpreparedness of training and documentation accompanied rollout. These were not reasonably enterprise ready at launch, or now. In 2010/2011 when systemd was first being integrated into Fedora (and I believe SuSE) I would have agreed with you. However this is four years later and I couldn't disagree with you more. More to the point, Red Hat disagrees with you, given that they have put their money where their mouth is and integrated systemd into RHEL7. > D) The architectural case that the services adopted in systemd over time belong there or are safe there is not proven, and not that I see well argued or documented. Conglomerated services are at least to be eyed skeptically. > > I did not closely follow systemd's development but it is evident from a distance that operator feedback in the community and to Sun regarding SMF flaws was somehow missed in systemd's development as they did the same wrong things. > > A change this big deserves architectural clarity and justification. I don't follow systemd development closely either, but Lennart Poettering, Kay Sievers, et. al. have made extraordinary attempts to communicating about systemd. They've appeared at numerous conferences and given talks about systemd, written blog posts, documentation, etc. I don't know what else they can do other than to be invited over to everyone's home for tea and a systemd discussion. > We get snide comments about change being good and core developers Linus evidently feels are unsafe. We also get snide comments about change being bad. As for Linus, other than the fact that he has an extraordinary amount of influence over what goes into the kernel, I've learned to take his comments on other matters with a very large grain of salt. I have a lot of respect for the guy, but his attitude and behavior towards other people is appalling. What's really surprising about some of Linus' comments WRT to systemd is that one of systemd's main goals is to make it easier to use some of the advanced functionality of the Linux kernel that were little used or ignored before. -- Jeff Ollie From bzs at world.std.com Wed Oct 22 18:31:02 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 14:31:02 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> Message-ID: <21575.63462.45782.746718@world.std.com> On October 21, 2014 at 16:43 morrowc.lists at gmail.com (Christopher Morrow) wrote: > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan wrote: > > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: > >> But > >> for example some of my servers boot in seconds. > > > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS > > Handbook_, available at > > it's really not clear to me that 'reboots in seconds' is a thing to optimize... The unix community has exerted great amounts of effort over the decades to speed up reboot, particularly after crashes but also planned. Perhaps you don't remember the days when an fsck was basically mandatory and could take 15-20 minutes on a large disk. Then we added the clean bit (disk unmounted cleanly, no need for fsck), reorg'd the file system layout to speed up fsck considerably and make it more reliable/recoverable, added journaled file systems which really sped things up often eliminating the need to fsck after a crash entirely and recovering in seconds, various attempts to figure out the dependency graph of servers and services which need to be started so they could be started in parallel where dependencies are met, etc. And learned how to do hot failover and master/slave servers etc. And you whisk all that away with "it's not really clear to me that 'reboots in seconds' is a think to be optimized"???? To me that's like saying it's not important to try to design so one can recover from a network outage in seconds. Anyhow, if it's not clear: I disagree. > > I suppose the win is: > "Is the startup/shutdown process clear, conscise and understandable > at 3am local time?" > > followed by: > "Can I adjust my startup processes to meet my needs easily and > without finding a phd in unix?" > > If systemd is simply a change in how I think about /etc/init.d/* and > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility > then it's a fail. Actually, much of that is less important except perhaps to a hobbyist. You only have to get the startup/shutdown process etc right once in a while and generally during a planned outage. Recovering from a failure or going back into service quickly after a planned outage is critical and can be critical at any time. Obviously one can appeal to extremum but what you say doesn't make sense to me. At any rate, you are disputing a huge, decades long, and widely fought battle. It's certainly not my opinion. -- -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 bzs at world.std.com Wed Oct 22 18:31:21 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 14:31:21 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5446C5A1.3040801@nic-naa.net> References: <5445AD63.7090400@lugosys.com> <5446C5A1.3040801@nic-naa.net> Message-ID: <21575.63481.947211.798330@world.std.com> On October 21, 2014 at 13:44 brunner at nic-naa.net (Eric Brunner-Williams) wrote: > > systemd is insanity. > > see also smit. SMIT! Rhymes with .... -- -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 asullivan at dyn.com Wed Oct 22 19:04:51 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 22 Oct 2014 15:04:51 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022170842.GB37494@dyn.com> Message-ID: <20141022190450.GE37494@dyn.com> On Wed, Oct 22, 2014 at 01:35:26PM -0400, Daniel Corbe wrote: > Not to get even further off topic here but when was the last time you > maintained a BSD system? FreeBSD (at least) adopted binary package > management as its preferred interface to ports through pkg-ng somewhere > in the 9-RELEASE cycle. Yeah, it was some time ago (fortunately, people keep me far away from systems administration now). But that doesn't exactly help: since others drew the same conclusion, _even if BSD is now a perfectly rational choice_, I've lost functionality I desire. Docker is a great example of this. For many use cases, it's obviously better than the alternatives. So now I _can't_ pick FreeBSD. And so on. > This systemd debacle is an excellent reason to look into stuff that > isn't Linux. The Linux camp all too often become victims of "not > invented here" I don't think the latter is restricted to the Linux world! But as I suggested, the network security implications of all that stuff hidden in one critical system sure seem to require some thinking. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From jschiel at flowtools.net Wed Oct 22 19:13:29 2014 From: jschiel at flowtools.net (John Schiel) Date: Wed, 22 Oct 2014 13:13:29 -0600 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <544801D9.9050004@flowtools.net> On 10/22/2014 10:43 AM, C. Jon Larsen wrote: > >> Hardly. The discussion so far has been weighted very heavily on the >> side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way >> it was and we liked it!". >> >> The people that like systemd (like myself) have wisely learned that >> the people that hate systemd, hate it mostly because it's different >> from what came before and don't want to change. There's no way to >> argue rationally with that. > > Incorrect assumption. systemd is a massive security hole waiting to > happen and it does not follow the unix philosophy of done 1 thing and > do it well/correct. i was beginning to wonder how secure systemd is also. --John > Its basically ignoring 40 years of best practices. Thats why folks > that have been there, done that, dont want any part of it. Not because > its new, but because its a flawed concept. > > You are free to use it, but it would be a poor choice for system that > has hopes of being secure. > >> -- >> Jeff Ollie >> >> From jeff at ocjtech.us Wed Oct 22 19:24:40 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 14:24:40 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <544801D9.9050004@flowtools.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> Message-ID: On Wed, Oct 22, 2014 at 2:13 PM, John Schiel wrote: > On 10/22/2014 10:43 AM, C. Jon Larsen wrote: >> >> Incorrect assumption. systemd is a massive security hole waiting to happen >> and it does not follow the unix philosophy of done 1 thing and do it >> well/correct. > > i was beginning to wonder how secure systemd is also. Personally, I feel that the systemd developers have given a lot of thought to security, both in the systemd code itself and because systemd makes it practical to use advanced features of the Linux kernel that can improve security. One example is the fact that systemd makes it very easy to give a service a private /tmp and /var/tmp directory that no other service uses by using Linux's filesystem namespaces. That can avoid all sorts of tmpfile race conditions that have caused problems in the past. Doing that in sysvinit, while possible, wasn't easy because you'd have to modify each init.d script (and redo the change every time upstream released a new update) to create/manage the filesystem namespace. In practice it was never done. -- Jeff Ollie From Valdis.Kletnieks at vt.edu Wed Oct 22 19:30:29 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 22 Oct 2014 15:30:29 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Your message of "Wed, 22 Oct 2014 13:13:29 -0600." <544801D9.9050004@flowtools.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> Message-ID: <21169.1414006229@turing-police.cc.vt.edu> On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: > i was beginning to wonder how secure systemd is also. One of the 3 CIA pillars of security is "availability". And if it's oh-dark-30, figuring out what symlink is supposed to be where for a given failed systemd unit can be a tad challenging. At least under sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). And if they carry through on their systemd-console threat, that could get even worse - that introduces a whole new pile of risks for being unable to diagnose early boot bugs So yeah, there's security issues other than "can it be hacked because it's got a huge surface area". (*) Unless you're really having a bad night and it's a hard link to /dev/sda1 or something. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jfbeam at gmail.com Wed Oct 22 19:31:29 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 22 Oct 2014 15:31:29 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <21575.63462.45782.746718@world.std.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: On Wed, 22 Oct 2014 14:31:02 -0400, Barry Shein wrote: > Perhaps you don't remember the days when an fsck was > basically mandatory and could take 15-20 minutes on a large disk. Journaling has all but done away with fsck. You'd have to go *way* back to have systems that ran a full fsck on every boot -- and in my experience, you absolutely wanted that fsck. I've used xfs for over a decade. It doesn't even have an fsck (xfs_check and xfs_repair, yes, but NO system will ever call them. And as a rule, never needs to.) > And you whisk all that away with "it's not really clear to me that > 'reboots in seconds' is a think to be optimized"???? You're arguing the difference between optimizing a 15min boot into a 5min boot, vs a 15sec "boot" into a 14sec "boot". The former is an actual optimization allowing subsystems to start in parallel, in ways that do not introduce delay. (eg. sendmail startup, used to be the #1 slow down on solaris) The latter is pure nonsense, with "boot" being measured as when login pops up -- which is NOT when all the subsystems have actually completely started. > To me that's like saying it's not important to try to design so one > can recover from a network outage in seconds. Your efforts are better spent avoiding an outage in the first place. If outages are common enough to be something that needs to be "sped up", then you've already failed. From bzs at world.std.com Wed Oct 22 19:32:09 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 15:32:09 -0400 Subject: Why is .gov only for US government agencies? In-Reply-To: References: <201410191212.s9JCCx5T037652@aurora.sol.net> <201410190951270460.00404B14@smtp.24cl.home> <93034.1413814845@turing-police.cc.vt.edu> <3374.1413819877@turing-police.cc.vt.edu> <21573.60568.636433.560229@world.std.com> <06C09C37-8FCE-41B4-8E93-84BCE9568EA5@tislabs.com> <1FB912BC-5FC8-4576-B340-EAA9A779E41B@virtualized.org> Message-ID: <21576.1593.187946.55871@world.std.com> On October 22, 2014 at 01:25 itg at itechgeek.com (ITechGeek) wrote: > Instead of multiple govs trying to use .gov or .mil, the best idea would be > to collapse .gov under .gov.us and .mil under .mil.us (Much like how other > countries already work). And of course they'll also keep .GOV and .MIL because it's too much trouble to do whatever it'd take to actually decomission them so not much would be accomplished. I'm not opposed to the idea, sure, why not, but I'm pessimstic that it'd accomplish much in our lifetimes (depending on your age of course.) > I don't see that happening as long as the US gov has a say in the matter. > I think .su will be decommissioned long before .gov or .mil are. We agree. Never attribute to megalomania that which can be adequately explained by inertia. -- -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 david at blue-labs.org Wed Oct 22 19:35:51 2014 From: david at blue-labs.org (David Ford) Date: Wed, 22 Oct 2014 19:35:51 +0000 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54477BD2.10905@meetinghouse.net> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> Message-ID: <54480717.2030609@blue-labs.org> > Which leads me to ask - those of you running server farms - what > distros are popular these days, for server-side operations? We've > been running Debian like forever (by way of Solaris and redhat) - but > this systemd thing is making me rethink things. Seems like an awful > lot of folks are now designing for the desktop, and it might be time > to migrate to a BSD or Solaris derivative. What are others doing? to be honest, i like systemd. nobody else has really stepped up to the bat to fix issues of existing init systems and tying interoperabilty into a common bus. not everything in systemd is a requirement to run it. just because a unit is offered for dhcp or ntp, doesn't mean you are required to use it. the vast majority of negative tongue wagging regarding systemd is ill informed. does systemd have growing pains? definitely. are some egos involved? sure. can systemd be far reaching? yes, is such reach mandated? no. use the units you want and disregard the rest. i run Arch Linux in my farms and except for the advanced networking functions and ease of locally tailoring Gentoo offered, I love Arch more than any of my .rpm or .deb flavors, *bsd or *nix, and i have used pretty much all of them. i've run unix like systems since 1988 and cover the gammut of code writing from bash scripts to kernel modules to apache and postgres on everything from microcontrollers to mainframes. before making ill informed rash decisions, study what you're talking about and then decide whether or not you like and can/can't use said subject. -d -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From bzs at world.std.com Wed Oct 22 19:38:11 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 15:38:11 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <5447826F.9080000@ninjabadger.net> <54478829.8080700@jack.fr.eu.org> Message-ID: <21576.1955.857318.126231@world.std.com> On October 22, 2014 at 12:00 md1clv at md1clv.com (Daniel Ankers) wrote: > On 22 October 2014 11:34, wrote: > > > Before leaving Debian, things to think: > > - will systemd be officialy the only system available ? > > - if so, won't we get a way to bypass that ? > > > > And one other thought... is it really that bad? > > Personally I like it a lot better than sysV plus inittab plus daemontools. I posted my complaints but I think they fall more in the realm of lack of maturity than bad design. I believe systemd is superior to sysvinit but it will take time for it to mature, administrative tools to become available (even if just better logging/tracing), and for us to get used to it and acquire the folk knowledge we need. Until then frustration will arise from time to time. -- -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 randy at psg.com Wed Oct 22 19:42:46 2014 From: randy at psg.com (Randy Bush) Date: Thu, 23 Oct 2014 04:42:46 +0900 Subject: Linux: concerns over systemd [OT] In-Reply-To: <21575.62558.449089.867918@world.std.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.62558.449089.867918@world.std.com> Message-ID: Barry Schein: > I'm reminded of the remark often attributed to DEC CEO Ken Olson, > roughly: > > With VMS (their big complex OS) it might take hours searching > through manuals to find a feature you need while with Unix you can > determine in seconds that it is not available. and how did that work out for vms? and digital? Jeffrey Ollie wrote: > > The people that like systemd (like myself) have wisely learned that > the people that hate systemd, hate it mostly because it's different > from what came before and don't want to change. There's no way to > argue rationally with that. and with this ad homina you dismiss all technical, architectural, and security concerns. much from folk who have been administering unix systems since you were in nappies. and you advocate rational argument? Daniel Corbe wrote: > Not to get even further off topic here but when was the last time you > maintained a BSD system? FreeBSD (at least) adopted binary package > management as its preferred interface to ports through pkg-ng > somewhere in the 9-RELEASE cycle. i am a long time bsd user and deployer. amelioration of shellshock, heartbleed, and poodle on an annoying number of servers was not any better on freebsd than debian. randy From bzs at world.std.com Wed Oct 22 19:47:01 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 15:47:01 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022110427.GA4921@gsp.org> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <20141022110427.GA4921@gsp.org> Message-ID: <21576.2485.41841.393808@world.std.com> On October 22, 2014 at 07:04 rsk at gsp.org (Rich Kulawiec) wrote: > I've seen similar tactical mistakes when developers insist that > information *must* be stored in a relational database -- even though > plain old ordinary text files are perfectly adequate for the task, > are easier to debug, are easier to fix, and easier to maintain. > There is an unfortunate tendency among many developers to attempt > to wring the very last bit of performance out of systems and not > to take into consideration that the scarcest and most expensive > resource is the system administrator. Saving a few microseconds > or a handful of bytes here and there is a horribly bad idea if it > chews up an extra hour or week of SA time. Obviously it depends on the application, generalities are dangerous. But one advantage of DBs are that you automatically get all the mechanics of failover, distribution, backup and recovery, atomicity, consistency, integrity, security, etc. that come with the DB essentially for "free". There is a tendency that one starts with this idea of keeping it simple, such as text files, and then proceeds to build all these mechanisms themselves, usually poorly. Look at how many different formats of configuration files we have on a typical *ix system, nearly one per application/daemon that needs a config file. Why do I have to know how to properly modify a passwd file, named config, logrotate, tcp wrappers, mail daemon configs, anti-spam configs, etc etc etc (usually in /etc!) down to what they will each take for a comment or separator or stanza syntax. -- -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 bzs at world.std.com Wed Oct 22 19:51:53 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 15:51:53 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5EA9A87201F2AB42BFD9B954797F19BE0338B21B@PRA-IAD-MAIL.pra.ray.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> <5EA9A87201F2AB42BFD9B954797F19BE0338B21B@PRA-IAD-MAIL.pra.ray.com> Message-ID: <21576.2777.349727.84982@world.std.com> On October 22, 2014 at 11:36 jamie.s.bowden at raytheon.com (Jamie Bowden) wrote: > > From: Bryan Tong > > > > The final fact is that bash itself is a dirty language that developers hate > > and system administrators love. > > Excuse me? I've been administering systems for over twenty years now and I can't say that I've ever even once chosen to use bash over any alternative; no matter how much that alternative might suck, bash sucks more. Your Linux addicts who've never used another flavor of Unix may be addicted to bash, but there's no helping some people. I wish I had a nickel for every time I started to implement something in bash/sh, used it a while, and quickly realized I needed something like perl and had to rewrite the whole thing. Sure, one can insist on charging forward in sh but at some point it becomes, as Ken Thompson so eloquently put it on another topic entirely, like kicking a dead whale down the beach. -- -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 mfidelman at meetinghouse.net Wed Oct 22 19:53:31 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 15:53:31 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54480717.2030609@blue-labs.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: <54480B3B.3080805@meetinghouse.net> David Ford wrote: >> Which leads me to ask - those of you running server farms - what >> distros are popular these days, for server-side operations? We've >> been running Debian like forever (by way of Solaris and redhat) - but >> this systemd thing is making me rethink things. Seems like an awful >> lot of folks are now designing for the desktop, and it might be time >> to migrate to a BSD or Solaris derivative. What are others doing? > > before making ill informed rash decisions, study what you're talking > about and then decide whether or not you like and can/can't use said > subject. Is that not the point of discussions like this one? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bzs at world.std.com Wed Oct 22 19:54:17 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Oct 2014 15:54:17 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447A671.6060005@satchell.net> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <20141022110427.GA4921@gsp.org> <5447A671.6060005@satchell.net> Message-ID: <21576.2921.22656.732335@world.std.com> On October 22, 2014 at 05:43 list at satchell.net (Stephen Satchell) wrote: > > How did this discussion get into NANOG? :) Because in the field of automotive engineering we are the ones who actually need to get down the road on time, reliably, and consistently while the automotive engineers probably take the bus where they can continue their design discussions. -- -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 jlarsen at richweb.com Wed Oct 22 20:03:36 2014 From: jlarsen at richweb.com (C. Jon Larsen) Date: Wed, 22 Oct 2014 16:03:36 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: <54480717.2030609@blue-labs.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: >> Which leads me to ask - those of you running server farms - what >> distros are popular these days, for server-side operations? We've >> been running Debian like forever (by way of Solaris and redhat) - but >> this systemd thing is making me rethink things. Seems like an awful >> lot of folks are now designing for the desktop, and it might be time >> to migrate to a BSD or Solaris derivative. What are others doing? > > to be honest, i like systemd. nobody else has really stepped up to the > bat to fix issues of existing init systems and tying interoperabilty > into a common bus. Perhaps because folks that understand more about security than you (and me for sure so I'm not picking on you) think thats a bad idea? If something is a bad idea then smart folks dont rush out (generally) to build it ... thus the no one stepping up to bat "problem" thats not really a problem - its a good thing to not have problems solved improperly. Perhaps because when you say/hear things like "tying interoperabilty into a common bus" you think thats a good idea. Others hear those same words and think: vendor lock-in single point of failure lack of choice The binary logging thing is a non-starter for a lot of folks. dbus ? On a server ? Do we really need that ? Lets keep servers reliable - less code not more (no bugs in unwritten code). Shouldnt the amount of code running as PID 1 be kept to an absolute minimum? Bad architecture decisions dont suddenly become good ones even if they solve other problems along the way or make some things better or faster. From jschiel at flowtools.net Wed Oct 22 20:22:58 2014 From: jschiel at flowtools.net (John Schiel) Date: Wed, 22 Oct 2014 14:22:58 -0600 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <21169.1414006229@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> Message-ID: <54481222.1090904@flowtools.net> On 10/22/2014 01:30 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: > >> i was beginning to wonder how secure systemd is also. > One of the 3 CIA pillars of security is "availability". And if > it's oh-dark-30, figuring out what symlink is supposed to be where > for a given failed systemd unit can be a tad challenging. At least under > sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). > > And if they carry through on their systemd-console threat, that could get > even worse - that introduces a whole new pile of risks for being unable > to diagnose early boot bugs > > So yeah, there's security issues other than "can it be hacked because > it's got a huge surface area". Agreed, the "oh-dark-thirty" call outs will be harder to resolve but I'm sure some folks will learn to deal with it. It's new and changes the job but as was noted earlier, there is always change. My concern is with the "large surface area". Does that expose the daemon to more vulnerabilities because it does more or does one daemon make it easier to protect against multiple vulnerabilities? I don't know, that's where the research needs to be done. --John > > (*) Unless you're really having a bad night and it's a hard link to /dev/sda1 > or something. :) From jeff at ocjtech.us Wed Oct 22 20:27:40 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 15:27:40 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <21169.1414006229@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> Message-ID: On Wed, Oct 22, 2014 at 2:30 PM, wrote: > On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: > >> i was beginning to wonder how secure systemd is also. > > One of the 3 CIA pillars of security is "availability". And if > it's oh-dark-30, figuring out what symlink is supposed to be where > for a given failed systemd unit can be a tad challenging. At least under > sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). How long has it been since you've looked at/used systemd? Manual management of symlinks to control what services are started at boot time are a thing of the past. "systemctl enable|disable|status " will handle all of that for you. I agree, managing symlinks was annoying in the early systemd days, but I haven't messed with those symlinks manually in a long time, except to remove orphan symlinks caused by services that weren't removed cleanly from the system. I think your fear comes more from a lack of familiarity with systemd, rather than a true technical deficit. Personally I find systemd services much easier to debug, especially since stderr and stdout from all services is captured, rather than being lost to /dev/null. I find it VERY annoying that many init.d scripts eventually boil down to "/usr/sbin/program --someflags 2>&1 > /dev/null &". > And if they carry through on their systemd-console threat, that could get > even worse - that introduces a whole new pile of risks for being unable > to diagnose early boot bugs I haven't seen much about systemd-console, but I thought that this reddit thread was interesting. http://www.reddit.com/r/linux/comments/1rmj9e/systemd_is_about_to_gain_a_system_console_boot/ It seems to me that moving VTs out of the kernel and into a userspace process would be a good thing. I guess one could argue about whether systemd is the right place for it, but as you can see from that reddit thread there have been a number of other projects that have attempted to do that but have failed to gain traction for one reason or another. One thing that the systemd developers are undeniably good at is getting their work adopted by the distributions. > So yeah, there's security issues other than "can it be hacked because > it's got a huge surface area". Nothing new here. And before you get started, Bash and OpenSSL prove that old code isn't necessarily secure code. -- Jeff Ollie From randy at psg.com Wed Oct 22 20:34:18 2014 From: randy at psg.com (Randy Bush) Date: Thu, 23 Oct 2014 05:34:18 +0900 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54480717.2030609@blue-labs.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: > the vast majority of negative tongue wagging regarding systemd is ill > informed. can we skip the ad homina and leave that for the systemd dev fora? > does systemd have growing pains? definitely. are some egos involved? > sure. can systemd be far reaching? yes, is such reach mandated? > no. use the units you want and disregard the rest. how does this work out in practice? at install, can i choose whether systemd is used for X as opposed for the separate component? can i template such choices for cluster deployment with the usual tools? as barry said, we get to drive this car. randy From jeff at ocjtech.us Wed Oct 22 20:40:30 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 15:40:30 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54481222.1090904@flowtools.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> <54481222.1090904@flowtools.net> Message-ID: On Wed, Oct 22, 2014 at 3:22 PM, John Schiel wrote: > > On 10/22/2014 01:30 PM, Valdis.Kletnieks at vt.edu wrote: >> >> On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: >> >>> i was beginning to wonder how secure systemd is also. >> >> One of the 3 CIA pillars of security is "availability". And if >> it's oh-dark-30, figuring out what symlink is supposed to be where >> for a given failed systemd unit can be a tad challenging. At least under >> sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). > > Agreed, the "oh-dark-thirty" call outs will be harder to resolve but I'm > sure some folks will learn to deal with it. It's new and changes the job but > as was noted earlier, there is always change. I disagree. I believe that the features of systemd will make "oh-dark-thirty" call outs easier to resolve, but only if you take the time to familiarize yourself with the tools at hand *before* problems happen. But really, there's nothing new here. *Of course* systems that are unfamiliar to you will be more difficult to fix. It'd take *me* *forever* to fix a problem on the HP-UX systems at work, mainly because I'd spend too much time figuring out where everything was. However the guy in the cube next to me wouldn't have that problem... To borrow Barry's automotive metaphor, this is like saying that electric motors are bad because I only know how to fix gasoline engines. -- Jeff Ollie From mfidelman at meetinghouse.net Wed Oct 22 20:41:37 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 16:41:37 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: <54481681.5090807@meetinghouse.net> Randy Bush wrote: >> the vast majority of negative tongue wagging regarding systemd is ill >> informed. > can we skip the ad homina and leave that for the systemd dev fora? > >> does systemd have growing pains? definitely. are some egos involved? >> sure. can systemd be far reaching? yes, is such reach mandated? >> no. use the units you want and disregard the rest. > how does this work out in practice? at install, can i choose whether > systemd is used for X as opposed for the separate component? can i > template such choices for cluster deployment with the usual tools? Right now, the problem is that the installer does not give a choice, and the preseed function has a bug such that you can't do a systemvinit install directly at install time; rather you have to let the default install complete, then replace systemd with sysvinit-core - and there seem to be cases of dropping into dependency hell when doing so (reports vary). Longer term, the above-mentioned bug will (hopefully) be patched (the patch is there, but not well tested, and has not yet been included into the installer). Then we get into the question of to what extent upstream packages start depending on systemd. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From Valdis.Kletnieks at vt.edu Wed Oct 22 20:48:43 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 22 Oct 2014 16:48:43 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: Your message of "Wed, 22 Oct 2014 19:35:51 -0000." <54480717.2030609@blue-labs.org> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: <25363.1414010923@turing-police.cc.vt.edu> On Wed, 22 Oct 2014 19:35:51 -0000, David Ford said: > into a common bus. not everything in systemd is a requirement to run it. > just because a unit is offered for dhcp or ntp, doesn't mean you are > required to use it. Actually, systemd 216 will cram systemd-timesyncd down your throat even if you had ntpd installed. https://bugzilla.redhat.com/show_bug.cgi?id=1136905 https://mail.gnome.org/archives/distributor-list/2014-September/msg00002.html Lennart's attitude was pretty much "why would anybody want to run ntpd when they have our SNTP implementation": http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html There's been similar issues with their dhcp. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mfidelman at meetinghouse.net Wed Oct 22 20:49:49 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 16:49:49 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> <54481222.1090904@flowtools.net> Message-ID: <5448186D.7000907@meetinghouse.net> Jeffrey Ollie wrote: > On Wed, Oct 22, 2014 at 3:22 PM, John Schiel wrote: >> On 10/22/2014 01:30 PM, Valdis.Kletnieks at vt.edu wrote: >>> On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said: >>> >>>> i was beginning to wonder how secure systemd is also. >>> One of the 3 CIA pillars of security is "availability". And if >>> it's oh-dark-30, figuring out what symlink is supposed to be where >>> for a given failed systemd unit can be a tad challenging. At least under >>> sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*). >> Agreed, the "oh-dark-thirty" call outs will be harder to resolve but I'm >> sure some folks will learn to deal with it. It's new and changes the job but >> as was noted earlier, there is always change. > I disagree. I believe that the features of systemd will make > "oh-dark-thirty" call outs easier to resolve, but only if you take the > time to familiarize yourself with the tools at hand *before* problems > happen. Easier said then done. 1. Experimentation and learning curve take time. That's a real cost that's being imposed. It's not clear that the benefits outweigh the costs of the status quo. 2. Assumes good documentation. Not a given with systemd, as it stands now. 3. Assumes that problems are easy to track down. Harder to do with murky and monolithic code. (I still shudder the first time udev did something completely counter-intuitive at 0-dark-30, and that's from the same cast of characters. 4. More fundamentally, 0-dark-30 events are almost always unexpected (other than in the sense of Murphy's Law), and tricky to resolve - one has hopefully prepared for the expected. Hence, it's not completely clear that one CAN familiarize oneself in a meaningful way - particularly when talking about something as monolithic as systemd. That's one of the major reasons for keeping things modular, and keeping modules simple. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From cma at cmadams.net Wed Oct 22 20:57:26 2014 From: cma at cmadams.net (Chris Adams) Date: Wed, 22 Oct 2014 15:57:26 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <25363.1414010923@turing-police.cc.vt.edu> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> <25363.1414010923@turing-police.cc.vt.edu> Message-ID: <20141022205726.GB18336@cmadams.net> Once upon a time, Valdis.Kletnieks at vt.edu said: > Actually, systemd 216 will cram systemd-timesyncd down your throat even > if you had ntpd installed. Yeah, I think a lot of the upset with systemd is not so much with the core daemon that runs as PID 1, but with the massive scope creep that the systemd project appears to have. Why should a project centered around an init system start reimplementing system logging, network management (and a DHCP client), clock management, etc.? > Lennart's attitude was pretty much "why would anybody want to run ntpd > when they have our SNTP implementation": Wow, maybe because SNTP is inferior to an actual NTP daemon in just about every way? -- Chris Adams From jeff at ocjtech.us Wed Oct 22 21:17:14 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 16:17:14 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: On Wed, Oct 22, 2014 at 3:34 PM, Randy Bush wrote: >> the vast majority of negative tongue wagging regarding systemd is ill >> informed. > > can we skip the ad homina and leave that for the systemd dev fora? I don't think that it's an ad homina attack, as it's pretty clear that many of the people commenting have not spent a significant time using systemd so many of their comments are based on what they've read on the Internet, not from practical experience with systemd. >> does systemd have growing pains? definitely. are some egos involved? >> sure. can systemd be far reaching? yes, is such reach mandated? >> no. use the units you want and disregard the rest. > > how does this work out in practice? at install, can i choose whether > systemd is used for X as opposed for the separate component? can i > template such choices for cluster deployment with the usual tools? I think that Debian's plan to allow multiple init systems (irregardless of which one is default) is a bad plan. The non-default ones won't get any love - at some point they'll just stop working (or indeed, work at all). Allowing choice of components is a good thing at one level (e.g. sendmail vs. postfix vs. exim). I really don't care (and don't really even remeber) which SMTP server is installed by default on my systems because my configuration management system makes sure that the SMTP server that I prefer is installed and configured the way I want it once the system is up and running. For something like PID 1, each distribution should make a choice and stick with it. I really couldn't care what Debian's init system is, as I don't use Debian (never have, at least not when I have had a choice). If Debian goes through with the switch to systemd, they won't gain me as a user as there are a host of other reasons that I prefer something other than Debian (or Debian-derived) distributions. If a group of people fork Debian because of systemd, more power to them. -- Jeff Ollie From jeff at ocjtech.us Wed Oct 22 21:33:52 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 16:33:52 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <25363.1414010923@turing-police.cc.vt.edu> References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> <25363.1414010923@turing-police.cc.vt.edu> Message-ID: On Wed, Oct 22, 2014 at 3:48 PM, wrote: > On Wed, 22 Oct 2014 19:35:51 -0000, David Ford said: > >> into a common bus. not everything in systemd is a requirement to run it. >> just because a unit is offered for dhcp or ntp, doesn't mean you are >> required to use it. > > Actually, systemd 216 will cram systemd-timesyncd down your throat even > if you had ntpd installed. Oh really? From my Fedora 21 (alpha) system at work: # rpm -q systemd systemd-216-5.fc21.x86_64 # systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled) Active: inactive (dead) Docs: man:systemd-timesyncd.service(8) # systemctl status ntpd.service ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: active (running) since Thu 2014-10-16 16:06:22 CDT; 6 days ago Main PID: 1438 (ntpd) CGroup: /system.slice/ntpd.service └─1438 /usr/sbin/ntpd -u ntp:ntp -g I'm not sure what NTP service is installed by default in Fedora 21+ (which will ship with systemd 216), as this system has been upgraded from previous Fedora versions, but as you can see it's perfectly possible to run ntpd on a system that used systemd 216. > https://bugzilla.redhat.com/show_bug.cgi?id=1136905 > https://mail.gnome.org/archives/distributor-list/2014-September/msg00002.html > > Lennart's attitude was pretty much "why would anybody want to run ntpd > when they have our SNTP implementation": A vast oversimplification of Lennart's point. Basically you left off "if you really want to run chronyd or ntpd service go right ahead, we're just not going to have code in systemd to do that for you". > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html > > There's been similar issues with their dhcp. The "bug" here is really timedatectl (a component of systemd) isn't going to manage chronyd or ntpd (third party packages), and that made a Gnome control panel (which used timedatectl under the hood) report that network time synchronization wasn't enabled. If you don't want timedated then it's perfectly possible to disable timedated and use something else. If someone cares enough, I'm sure that the Gnome control panel will get updated so that I can manage chronyd or ntpd itself. -- Jeff Ollie From randy at psg.com Wed Oct 22 21:40:44 2014 From: randy at psg.com (Randy Bush) Date: Thu, 23 Oct 2014 06:40:44 +0900 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5448186D.7000907@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> <54481222.1090904@flowtools.net> <5448186D.7000907@meetinghouse.net> Message-ID: > 4. More fundamentally, 0-dark-30 events are almost always unexpected > (other than in the sense of Murphy's Law), and tricky to resolve - one > has hopefully prepared for the expected. "If it was part of the 'plan' it’s an event; if it is not then it’s a 'disaster'" From rsk at gsp.org Wed Oct 22 21:43:36 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 22 Oct 2014 17:43:36 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <20141022214335.GA8447@gsp.org> On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote: > The people that like systemd (like myself) have wisely learned that > the people that hate systemd, hate it mostly because it's different > from what came before and don't want to change. That's an entirely unfair characterization. Some of us, including a lot of people on this list, have been pushing the envelope on change for decades. We've run alpha software on beta hardware, cobbled together networks with duct tape, and burned a lot of midnight oil while making innumerable mistakes and learning from them. Speaking for myself, after migrating through far too many Unix and Linux distributions to count, starting with Research Unix v6, my entire professional career has been *constant* change. I suspect that the same is true of everyone else who's been doing this for a while. Anyone who doesn't embrace change as a way of life probably isn't on this list; they're somewhere else, maintaining Cobol written during the Nixon administration. My problem with systemd is not that it's a change: it's just one more out of tens of thousands and so, in that sense, it's really not a big deal. My problem with it is that I think it's a bad change, one not in keeping with the "software tools" philosophy that has served us ridiculously well for a very long time and -- so far -- has not been shown itself to be in need of replacement. A Leatherman pocket multitool is highly useful: I've had one for years. It's great. Until you need two screwdrivers at the same time...at which point it becomes obvious why serious mechanics/craftsmen carry around a toolbox with dozens of tools and why glomming all of those into one supertool would be A Very Bad Move. Similarly, the monolithic (and ever-expanding) nature of systemd is a strategic design error. That's probably not obvious to people who measure their experience in years instead of decades -- it wouldn't have been obvious to me back in the day either. But it's pretty clear from here, and dismissing it as "hey you kids get off my lawn" geezer whining is not going to advance the discussion. It would be better, I think, to pull out a copy of Kernighan and Plauger's book -- which is rather brief, actually -- read it cover-to-cover, and then consider carefully whether the myriad-and-steadily-increasing number of functions being subsumed by systemd should actually be in one program. If that doesn't suffice, then I suspect it will only require waiting a little while until a demonstration of why monolithic integration is a bad idea will be provided by someone who is at this moment studying the large-and-growing attack surface presented by systemd. I hope I'm wrong about that. I'm probably not. (By the way, this should not be read to express unabashed support for *any* of the various init systems that have been present in SysV or BSD or AIX or Debian or Dynix or Red Hat or HPUX or Mint or Ultrix or Solaris or or or or. They all have their issues, some of which were or are sporadically annoying.) ---rsk From gary.buhrmaster at gmail.com Wed Oct 22 21:45:45 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 22 Oct 2014 21:45:45 +0000 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: On Wed, Oct 22, 2014 at 9:17 PM, Jeffrey Ollie wrote: .... > I think that Debian's plan to allow multiple init systems > (irregardless of which one is default) is a bad plan. The non-default > ones won't get any love - at some point they'll just stop working (or > indeed, work at all). Indeed. I believe that point was made during the debian technical committee discussions by one of the members of the TC (Russ, I think, although it was such a long discussion it could have been one of the other participants). From nanog at jack.fr.eu.org Wed Oct 22 21:48:28 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 22 Oct 2014 23:48:28 +0200 Subject: Linux: concerns over systemd [OT] In-Reply-To: <21575.63462.45782.746718@world.std.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: <5448262C.50406@jack.fr.eu.org> Bah, boot speed; On my server, boot is slow down by hardware initialization. The soft side is quite low. But the point is not "makes things faster from 15 to 14 sec is useless". The point is : it's good, but at what price ? As you said, there were many improvements over the past. What was the "clean bit" cost ? None but benefits, right ? What about fs logs ? Does it have a cost ? If systemd is just about time, it will be fine. But why trying to recreate (ans thus, squeeze) some old daemons like cron or syslog ? Both of them are doing a perfect job. Can I use systemd without any of journald stuff ? If not, then the 1sec speedup is far too expensive. On 22/10/2014 20:31, Barry Shein wrote: > > On October 21, 2014 at 16:43 morrowc.lists at gmail.com (Christopher Morrow) wrote: > > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan wrote: > > > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote: > > >> But > > >> for example some of my servers boot in seconds. > > > > > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS > > > Handbook_, available at > > > > it's really not clear to me that 'reboots in seconds' is a thing to optimize... > > The unix community has exerted great amounts of effort over the > decades to speed up reboot, particularly after crashes but also > planned. Perhaps you don't remember the days when an fsck was > basically mandatory and could take 15-20 minutes on a large disk. > > Then we added the clean bit (disk unmounted cleanly, no need for > fsck), reorg'd the file system layout to speed up fsck considerably > and make it more reliable/recoverable, added journaled file systems > which really sped things up often eliminating the need to fsck after a > crash entirely and recovering in seconds, various attempts to figure > out the dependency graph of servers and services which need to be > started so they could be started in parallel where dependencies are > met, etc. > > And learned how to do hot failover and master/slave servers etc. > > And you whisk all that away with "it's not really clear to me that > 'reboots in seconds' is a think to be optimized"???? > > To me that's like saying it's not important to try to design so one > can recover from a network outage in seconds. > > Anyhow, if it's not clear: I disagree. > > > > > I suppose the win is: > > "Is the startup/shutdown process clear, conscise and understandable > > at 3am local time?" > > > > followed by: > > "Can I adjust my startup processes to meet my needs easily and > > without finding a phd in unix?" > > > > If systemd is simply a change in how I think about /etc/init.d/* and > > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility > > then it's a fail. > > Actually, much of that is less important except perhaps to a hobbyist. > > You only have to get the startup/shutdown process etc right once in a > while and generally during a planned outage. > > Recovering from a failure or going back into service quickly after a > planned outage is critical and can be critical at any time. > > Obviously one can appeal to extremum but what you say doesn't make > sense to me. At any rate, you are disputing a huge, decades long, and > widely fought battle. It's certainly not my opinion. > > From mfidelman at meetinghouse.net Wed Oct 22 21:54:18 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 17:54:18 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022214335.GA8447@gsp.org> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> Message-ID: <5448278A.6000007@meetinghouse.net> Well said, Rich. Rich Kulawiec wrote: > On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote: >> The people that like systemd (like myself) have wisely learned that >> the people that hate systemd, hate it mostly because it's different >> from what came before and don't want to change. > That's an entirely unfair characterization. > > Some of us, including a lot of people on this list, have been pushing the > envelope on change for decades. We've run alpha software on beta hardware, > cobbled together networks with duct tape, and burned a lot of midnight oil > while making innumerable mistakes and learning from them. > > Speaking for myself, after migrating through far too many Unix > and Linux distributions to count, starting with Research Unix v6, > my entire professional career has been *constant* change. I suspect > that the same is true of everyone else who's been doing this for a while. > Anyone who doesn't embrace change as a way of life probably isn't on > this list; they're somewhere else, maintaining Cobol written during > the Nixon administration. > > My problem with systemd is not that it's a change: it's just one more > out of tens of thousands and so, in that sense, it's really not a big deal. > My problem with it is that I think it's a bad change, one not in keeping > with the "software tools" philosophy that has served us ridiculously > well for a very long time and -- so far -- has not been shown itself > to be in need of replacement. > > A Leatherman pocket multitool is highly useful: I've had one for years. > It's great. Until you need two screwdrivers at the same time...at which > point it becomes obvious why serious mechanics/craftsmen carry around a > toolbox with dozens of tools and why glomming all of those into one > supertool would be A Very Bad Move. > > Similarly, the monolithic (and ever-expanding) nature of systemd is a > strategic design error. That's probably not obvious to people who > measure their experience in years instead of decades -- it wouldn't > have been obvious to me back in the day either. But it's pretty clear > from here, and dismissing it as "hey you kids get off my lawn" geezer > whining is not going to advance the discussion. It would be better, > I think, to pull out a copy of Kernighan and Plauger's book -- which > is rather brief, actually -- read it cover-to-cover, and then consider > carefully whether the myriad-and-steadily-increasing number of functions > being subsumed by systemd should actually be in one program. > > If that doesn't suffice, then I suspect it will only require waiting > a little while until a demonstration of why monolithic integration > is a bad idea will be provided by someone who is at this moment > studying the large-and-growing attack surface presented by systemd. > > I hope I'm wrong about that. I'm probably not. > > (By the way, this should not be read to express unabashed support > for *any* of the various init systems that have been present in SysV > or BSD or AIX or Debian or Dynix or Red Hat or HPUX or Mint or Ultrix > or Solaris or or or or. They all have their issues, some of which > were or are sporadically annoying.) > > ---rsk -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jeff at ocjtech.us Wed Oct 22 22:10:36 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 17:10:36 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5448186D.7000907@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <544801D9.9050004@flowtools.net> <21169.1414006229@turing-police.cc.vt.edu> <54481222.1090904@flowtools.net> <5448186D.7000907@meetinghouse.net> Message-ID: On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman wrote: > > 1. Experimentation and learning curve take time. That's a real cost that's > being imposed. What makes systemd different from any other technology in that respect? > It's not clear that the benefits outweigh the costs of the status quo. Ultimately this is a very personal decision, but given the adoption rate of systemd by distributions I don't think that it's going to be that long before people (at least if you want to be employed managing Linux systems) don't have a choice but to become at least passably familiar with systemd. Even if Debian steps back from systemd, Canonical and Red Hat have committed to systemd. > 2. Assumes good documentation. Not a given with systemd, as it stands now. Why does everyone assume that systemd doesn't have good documentation? I personally have found the documentation to be excellent. > 3. Assumes that problems are easy to track down. Harder to do with murky > and monolithic code. Statements that are equally valid for sysvinit. > (I still shudder the first time udev did something > completely counter-intuitive at 0-dark-30, and that's from the same cast of > characters. Udev predates systemd, by a long long time. If you have problems with udev don't blame systemd. > 4. More fundamentally, 0-dark-30 events are almost always unexpected (other > than in the sense of Murphy's Law), and tricky to resolve - one has > hopefully prepared for the expected. Hence, it's not completely clear that > one CAN familiarize oneself in a meaningful way - particularly when talking > about something as monolithic as systemd. That's one of the major reasons > for keeping things modular, and keeping modules simple. This really has nothing to do with systemd. I believe that systemd has made things better in this respect, but you're welcome to believe that the pile of shell scripts in /etc/init.d is better. I mean really, what could go wrong when we configure boot-up with a Turing complete language? Really... I know of several instances a poorly-written init script caused boot-up to fail because they had infinite loops in them. -- Jeff Ollie From jeff at ocjtech.us Wed Oct 22 23:05:20 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 18:05:20 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022214335.GA8447@gsp.org> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> Message-ID: On Wed, Oct 22, 2014 at 4:43 PM, Rich Kulawiec wrote: > On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote: >> The people that like systemd (like myself) have wisely learned that >> the people that hate systemd, hate it mostly because it's different >> from what came before and don't want to change. > > That's an entirely unfair characterization. > > Some of us, including a lot of people on this list, have been pushing the > envelope on change for decades. We've run alpha software on beta hardware, > cobbled together networks with duct tape, and burned a lot of midnight oil > while making innumerable mistakes and learning from them. > > Speaking for myself, after migrating through far too many Unix > and Linux distributions to count, starting with Research Unix v6, > my entire professional career has been *constant* change. I suspect > that the same is true of everyone else who's been doing this for a while. > Anyone who doesn't embrace change as a way of life probably isn't on > this list; they're somewhere else, maintaining Cobol written during > the Nixon administration. Been there, done that, got the T-shirt. > My problem with systemd is not that it's a change: it's just one more > out of tens of thousands and so, in that sense, it's really not a big deal. > My problem with it is that I think it's a bad change, one not in keeping > with the "software tools" philosophy that has served us ridiculously > well for a very long time and -- so far -- has not been shown itself > to be in need of replacement. > > A Leatherman pocket multitool is highly useful: I've had one for years. > It's great. Until you need two screwdrivers at the same time...at which > point it becomes obvious why serious mechanics/craftsmen carry around a > toolbox with dozens of tools and why glomming all of those into one > supertool would be A Very Bad Move. I carry a Leatherman too, and indeed it is a very useful tool. But it's useful in the real world because physical tools have mass, and there's only so much mass that a person wants to carry around with them all of the time. In all other respects the tools on a Leatherman are far less superior than a tool purposely designed for a task. Software doesn't have mass so your analogy doesn't quite work. systemd is a tool designed to get the system to a state where "real work" can be done. NTP servers, DHCP clients, consoles, aren't the real work of a system, or at least I hope not, because that would be boring to me. I'm not going to justify everything that the systemd developers have done here, but I've been convinced that the functions that they have moved into systemd have been justified because it'll make systems work better and more robustly. > Similarly, the monolithic (and ever-expanding) nature of systemd is a > strategic design error. That's probably not obvious to people who > measure their experience in years instead of decades -- it wouldn't > have been obvious to me back in the day either. But it's pretty clear > from here, and dismissing it as "hey you kids get off my lawn" geezer > whining is not going to advance the discussion. You may have been in the "biz" longer than I have, but not by as much as you think. I didn't "immediately" see the value of systemd, but it didn't take me long. Your arguments still come off as appeal to tradition. It was impolite to call it old geezer whining was impolite but that doesn't change the nature of your argument. > It would be better, > I think, to pull out a copy of Kernighan and Plauger's book -- which > is rather brief, actually -- read it cover-to-cover, and then consider > carefully whether the myriad-and-steadily-increasing number of functions > being subsumed by systemd should actually be in one program. It's been a while since I've read it, but ISTR that the modularity that K&P speak of refers to procedures and functions, they didn't seem especially afraid of "big" programs. And from what I've seen the systemd code is properly modularized in the sense that K&P use. Speaking of which, did you know that sysvinit has no unit tests (or tests of any other kind)? And since every init script is code (even though many people treat it like configuration data) why don't they have unit tests either? systemd has an extensive test suite, that gives me some reassurance that bugs, once found, won't be reintroduced. And I'm sure that if we went through the Elements of Programming Style point by point there is much more in systemd's favor. > If that doesn't suffice, then I suspect it will only require waiting > a little while until a demonstration of why monolithic integration > is a bad idea will be provided by someone who is at this moment > studying the large-and-growing attack surface presented by systemd. > > I hope I'm wrong about that. I'm probably not. Software is software. I'm sure that bugs (including security bugs) will be found. Film at 11. Nothing new here. -- Jeff Ollie From list at satchell.net Wed Oct 22 23:07:01 2014 From: list at satchell.net (Stephen Satchell) Date: Wed, 22 Oct 2014 16:07:01 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141022214335.GA8447@gsp.org> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> Message-ID: <54483895.8030407@satchell.net> On 10/22/2014 02:43 PM, Rich Kulawiec wrote: > A Leatherman pocket multitool is highly useful: I've had one for years. > It's great. Until you need two screwdrivers at the same time...at which > point it becomes obvious why serious mechanics/craftsmen carry around a > toolbox with dozens of tools and why glomming all of those into one > supertool would be A Very Bad Move. I find this analogy very, very interesting. I'm looking at my Leatherman tool, and see that every single tool is based on a standard; nothing "invented here just for the Leatherman." The Phillips screwdriver is the standard P2 shape, not some off-the-wall grinding. And so forth. > Similarly, the monolithic (and ever-expanding) nature of systemd is a > strategic design error. That's probably not obvious to people who > measure their experience in years instead of decades -- it wouldn't > have been obvious to me back in the day either. But it's pretty clear > from here, and dismissing it as "hey you kids get off my lawn" geezer > whining is not going to advance the discussion. It's one thing to integrate a bridge to existing functions into a system. It's another to re-invent things for the sake of re-inventing them. If you have a perfectly good DHCP package, work *with* it instead of going through the trial of building and debugging your own version. Why duplicate effort? Why have two of something that has to be maintained instead of concentrating on improving the one you have? Now, sometimes you do have to sit down and say "this is hopeless, let's start from scratch" -- particularly when it was done to a bad spec and tried to do too much without step-wise refinement. (healthcare.gov, anyone?) But even when HeartBleed-SSH was forked, it wasn't abandoned and started from scratch; the BSD people just pruned all the non-POSIX guck and stripped it down to essentials. And did a proper security audit. We don't need systemd to turn into a hydra. If there is an issue with NTP or DHCP or whatever, systemd developers should go to the upstream and fix the issue in that package, not clone its own version and, perhaps, make the same mistakes all over again. From jeff at ocjtech.us Wed Oct 22 23:30:10 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 18:30:10 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5448262C.50406@jack.fr.eu.org> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <5448262C.50406@jack.fr.eu.org> Message-ID: On Wed, Oct 22, 2014 at 4:48 PM, wrote: > Bah, boot speed; > > On my server, boot is slow down by hardware initialization. > The soft side is quite low. > > But the point is not "makes things faster from 15 to 14 sec is useless". > The point is : it's good, but at what price ? I agree that "boot speed" is a red herring. Booting in a highly dynamic environment is really one of systemd's key achievements. True, this is most apparent in systems like laptops that can be docked/undocked, tend to have a lot of USB devices added/removed, etc. But servers have these same issues, if only in lesser degree. sysvinit generally had to wait for a fixed interval for all hardware to finish initializing. It was a little more sophisticated than one init script having a "sleep X" command in it, but not much. systemd is able to start services as soon as all of the hardware it needs is ready, rather than waiting arbitrary amounts of time and then possibly failing anyway because it didn't wait long enough. One main example of this is a large RAID array or LVM volume that's used for data storage (not the OS). systemd can let parts of the system boot that don't require the data storage to be present start up while waiting for all of the data storage drives to spin up and get assembled. > As you said, there were many improvements over the past. > What was the "clean bit" cost ? None but benefits, right ? > What about fs logs ? Does it have a cost ? > > If systemd is just about time, it will be fine. > But why trying to recreate (ans thus, squeeze) some old daemons like > cron or syslog ? Both of them are doing a perfect job. Syslog didn't capture the stdout/stderr from daemon start up. Syslog did only a mediocre job of capturing dmesg from early boot. If you have access to a system running systemd/journald run "journalctl -k -b". That'll show you all of the kernel messages since the last boot. At least on the RHEL systems that I have access to, /var/log/dmesg doesn't timestamp the lines in the file, making it difficult to impossible to correlate with other log lines. The kernel messages in /var/log/messages are timestamped with the time that rsyslog was able to (finally) start and pull the messages out of the kernel message buffer. > Can I use systemd without any of journald stuff ? I wouldn't want to. > If not, then the 1sec speedup is far too expensive. The boot speed up is a nice benefit, but not the only (or even the best) reason to use systemd. -- Jeff Ollie From larrysheldon at cox.net Wed Oct 22 23:58:47 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 22 Oct 2014 18:58:47 -0500 Subject: Self destruction in open source systems (was Re: Linux: concerns over systemd [OT]) In-Reply-To: <6B591p01V1cZc5601B5B9R> References: <201410221052.s9MAqBZt096450@aurora.sol.net> <6B591p01V1cZc5601B5B9R> Message-ID: <544844B7.5050900@cox.net> On 10/22/2014 06:01, Randy Bush wrote: >>>> Which leads me to ask - those of you running server farms - what >>>> distros are popular these days, for server-side operations? >>> been running bsd forever. but moving to debian and ganeti, as bsd >>> does not host virtualization. >> Simply not true; http://bhyve.org/ >> It is a bit immature compared to Xen+Ganeti or something like that. > > apologies. i thought we were talking about production systems. my > mistake. This may take us far enough away from BGP and prefix lengths to draw moderator fire, but it is a topic I would like to pursue somewhere. What is it about seems to mandate that they develop a fatal rot from the inside out? I don't have anything to add to the xxxxxX OSes (they Were Not Allowed when I was an active admin), but I have of late been grappling with what to do about replacing Firefox and Thunderbird in the four machines I have left in my world. Early on I developed a fondness for Mosaic as a simple get-the-job done tool to add to elm and news to get the work done. Netscape did a nice integration and I went with that until it went away. Now I have Thunderbird and Firefox--from people who are committed to the notion that if it works, it must be replaced. If people like it, it must be redesigned. If it is stable, it must be updated. If there is a useless, senseless "feature" somewhere in the world, these products must be revised to make that feature the focus. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From israel.lugo at lugosys.com Thu Oct 23 00:36:09 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 23 Oct 2014 01:36:09 +0100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> Message-ID: <54484D79.1070607@lugosys.com> On 10/23/2014 12:05 AM, Jeffrey Ollie wrote: > systemd is a tool designed to get the system to a state where "real > work" can be done. NTP servers, DHCP clients, consoles, aren't the > real work of a system, or at least I hope not, because that would be > boring to me. That idea sounds interesting. I can see where you're coming from. Basically, these things are "details", that shouldn't really be all that important, so systemd is supposed to take care of it all and leave you to worry about the actual bread and butter. That about it? Legitimate question, not trying to be sarcastic: would you concede that the amount to which something is a "detail" may vary significantly per the use case, and requirements? On my desktop I might not care about whatever the DHCP client is doing, or the NTP server, but on a server that may very well be a different story. For example, I'm very interested in NTP and accurate timekeeping -- mostly as a personal hobby, but it's been useful at work as well. I for one would definitely not consider NTP one of those "details" that just "come with the bootup process". > [regarding the Leatherman] > Software doesn't have mass so your analogy doesn't quite work. Analogies can only be taken so far before they cease to make sense. However, in the software world you could consider a "mass" equivalent: code size / complexity. Building on that, just as the Leatherman can't be as good as all the individual tools combined without weighing too much, one could say systemd can't be as good as all the individual tools it aims to replace without being too big and complex. Program "mass", in this case, may impact anything from performance, to ease of configuration, to complicated dependencies, to security problems. I did find it interesting, however, what you mentioned in another email, about systemd implementing certain isolation features such as separate filesystem namespaces and so on. That may be very useful. I think the main point that we could hopefully all agree on here, is that it would be very difficult to have a single "one size fits all" solution. The requirements and concerns of the desktop, for example, are simply too different from those of the server or router space. systemd, for better or for worse, can't be the one magic bullet. Great or terrible as though it may be, I don't much like the total break in compatibility (correct me if I'm wrong). I'm not saying SysV is all that good, but there are other replacements, and new ones can be designed, but don't make it so that everyone-has-to-use-yours-or-else! I guess we have GNOME to thank for that... And that's what troubles me the most: the lack of choice that seems to be creeping up, with everyone just ganging up and jumping to systemd like the floor is on fire. I'm with Jay Ashworth on this one: what gives?? Also, for the person who considered this OT for not being about Cisco, keep in mind all the world is not a VAX^H^H^HCisco ;) From aegal at cisco.com Thu Oct 23 00:40:32 2014 From: aegal at cisco.com (Abdulkadir Egal (aegal)) Date: Thu, 23 Oct 2014 00:40:32 +0000 Subject: Jared Mauch In-Reply-To: <5447249D.5030301@cox.net> References: <5447249D.5030301@cox.net> Message-ID: Congratulations Jared. Excellent work as always. Regards Abdul On 10/21/14 8:29 PM, "Larry Sheldon" wrote: >I don't remember seeing mention of this here: > >https://www.youtube.com/watch?v=69-qhoS9sSw > >h/t Suresh Ramasubramian on Facebook. > >(I didn't copy and paste any names--hope I got them right.) >-- >The unique Characteristics of System Administrators: > >The fact that they are infallible; and, > >The fact that they learn from their mistakes. > >Quis custodiet ipsos custodes From jeff at ocjtech.us Thu Oct 23 01:24:15 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 20:24:15 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54484D79.1070607@lugosys.com> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> Message-ID: On Wed, Oct 22, 2014 at 7:36 PM, Israel G. Lugo wrote: > > For example, I'm very interested in NTP and accurate timekeeping -- > mostly as a personal hobby, but it's been useful at work as well. I for > one would definitely not consider NTP one of those "details" that just > "come with the bootup process". As you can see in another email I posted, it's trivially easy to disable systemd's NTP implementation and replace it with another. The same goes for systemd's DHCP server, as far as I know there's no distribution using it by default yet. Fedora is still using NetworkManager, I think that RHEL 7 defaults to the same network scripts that have always been used, although it's very easy to switch to NetworkManager if that's what you want. So a lot of the whining you see about systemd "forcing" a NTP or DHCP server on you is hyperbole by people that have read a few articles on slashdot/reddit/whatever and take that as gospel. > I did find it interesting, however, what you mentioned in another email, > about systemd implementing certain isolation features such as separate > filesystem namespaces and so on. That may be very useful. Yes, indeed, very useful. > I think the main point that we could hopefully all agree on here, is > that it would be very difficult to have a single "one size fits all" > solution. The requirements and concerns of the desktop, for example, are > simply too different from those of the server or router space. I have found the "desktop" vs. "server" arguments with respect to systemd unconvincing. I find many/most of the features of systemd useful in both contexts. I think that the problem with the desktop/server dichotomy is that servers are no longer what they used to be. Servers used to be these things that sat in the back room and would reboot once or twice a year when a kernel upgrade needed to be applied. With the advent of "the cloud" and related technologies servers have become much more dynamic and then the advantages of systemd become much more obvious. > systemd, > for better or for worse, can't be the one magic bullet. Great or > terrible as though it may be, I don't much like the total break in > compatibility (correct me if I'm wrong). "total break in compatibility" is a bit much, as the systemd developers went to great lengths to make sure that init scripts continue to work pretty much as you would hope them to under systemd. > I'm not saying SysV is all that > good, but there are other replacements, and new ones can be designed, > but don't make it so that everyone-has-to-use-yours-or-else! No one forced Debian to adopt systemd except Debian. If Debian does go through with the switch no one is forcing you to stick with Debian. > I guess we have GNOME to thank for that... Well, I guess the Gnome developers saw some value in systemd integration that others don't. There are other desktop environments out there. > And that's what troubles me the most: > the lack of choice that seems to be creeping up, with everyone just > ganging up and jumping to systemd like the floor is on fire. I'm with > Jay Ashworth on this one: what gives?? Somehow I doubt that Lennart Poettering has the hypnotoad (ALL HAIL THE HYPNOTOAD!) in his pocket. I don't think that Lennart Poettering is a billionaire and can afford to bribe everyone in charge of all of the distributions (and I'm sure that most of them wouldn't take one anyway). Why do people keep assuming some sort of evil conspiracy on the part of the systemd developers and refuse to believe that systemd is becoming the default because the right people in the right places have been convinced of systemd's technical benefits over sysvinit? The reason that there's lack of choice is because the people that don't want systemd haven't stepped up to do the work and create their own distribution. -- Jeff Ollie From mfidelman at meetinghouse.net Thu Oct 23 01:35:19 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 21:35:19 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54484D79.1070607@lugosys.com> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> Message-ID: <54485B57.8060406@meetinghouse.net> Israel G. Lugo wrote: > On 10/23/2014 12:05 AM, Jeffrey Ollie wrote: > >> systemd is a tool designed to get the system to a state where "real >> work" can be done. NTP servers, DHCP clients, consoles, aren't the >> real work of a system, or at least I hope not, because that would be >> boring to me. Depends on the system. > > Legitimate question, not trying to be sarcastic: would you concede that > the amount to which something is a "detail" may vary significantly per > the use case, and requirements? On my desktop I might not care about > whatever the DHCP client is doing, or the NTP server, but on a server > that may very well be a different story. Re. NTP: Timekeeping is rather essential in lots of applications - like, for example, transit operations, where I currently spend my work life. An accurate, accessible central clock tends to be a rather important system component. And we're talking concerns in the range of seconds. When you start getting into serious real-time systems (laboratory instrumentation, utility operations, warfighting, ....) - yeah, NTP servers start getting really interesting, to a lot of people. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jeff at ocjtech.us Thu Oct 23 01:45:01 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 20:45:01 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54485B57.8060406@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> Message-ID: On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman wrote: > > Re. NTP: Timekeeping is rather essential in lots of applications - like, for > example, transit operations, where I currently spend my work life. An > accurate, accessible central clock tends to be a rather important system > component. And we're talking concerns in the range of seconds. When you > start getting into serious real-time systems (laboratory instrumentation, > utility operations, warfighting, ....) - yeah, NTP servers start getting > really interesting, to a lot of people. As I've already said a couple of times, systemd does not force a particular NTP implementation on you. It comes with one (timedated), and has a utility to manage it (timedatectl) but the admin can install and use a different one if they like. The only thing that has changed recently with respect to that is that timedatectl can no longer be used to manage chronyd or ntpd. -- Jeff Ollie From joe at nethead.com Thu Oct 23 01:52:58 2014 From: joe at nethead.com (Joe Hamelin) Date: Wed, 22 Oct 2014 18:52:58 -0700 Subject: Self destruction in open source systems (was Re: Linux: concerns over systemd [OT]) In-Reply-To: <544844B7.5050900@cox.net> References: <201410221052.s9MAqBZt096450@aurora.sol.net> <544844B7.5050900@cox.net> Message-ID: On Wed, Oct 22, 2014 at 4:58 PM, Larry Sheldon wrote: > > Now I have Thunderbird and Firefox--from people who are committed to the > notion that if it works, it must be replaced. If people like it, it must > be redesigned. If it is stable, it must be updated. If there is a > useless, senseless "feature" somewhere in the world, these products must be > revised to make that feature the focus. And where is my new 1967 VW Microbus? That's all you need if you compile it with --add-heater-fan. So I had to upgrade to a 1998 Volvo V70 wagon. Don't know where I'm going to get a new one when this one wears out. Damn kids, GET OFF MY LAWN! I actually feel with your there, Larry. I really like the *nixes because of the great app store with things like ls, grep, sed, cc and ssh. It's also why for most things I still use one of the BSDs. (Should we call /usr/ports an app store now?) -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From mfidelman at meetinghouse.net Thu Oct 23 02:08:34 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 22:08:34 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> Message-ID: <54486322.7020005@meetinghouse.net> Hey... how about not using selective editing to change the thread of discussion (see below) Jeffrey Ollie wrote: > On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman > wrote: >> Re. NTP: Timekeeping is rather essential in lots of applications - like, for >> example, transit operations, where I currently spend my work life. An >> accurate, accessible central clock tends to be a rather important system >> component. And we're talking concerns in the range of seconds. When you >> start getting into serious real-time systems (laboratory instrumentation, >> utility operations, warfighting, ....) - yeah, NTP servers start getting >> really interesting, to a lot of people. > As I've already said a couple of times, systemd does not force a > particular NTP implementation on you. It comes with one (timedated), > and has a utility to manage it (timedatectl) but the admin can install > and use a different one if they like. > > The only thing that has changed recently with respect to that is that > timedatectl can no longer be used to manage chronyd or ntpd. > What you snipped out of the message was YOUR previous statement, to which I was responding: > systemd is a tool designed to get the system to a state where "real > work" can be done. NTP servers, DHCP clients, consoles, aren't the > real work of a system, or at least I hope not, because that would be > boring to me. If you're going to simply keep repeating "I like systemd, everything is copacetic" - maybe you should take your fanboy attitude elsewhere, and let those of us concerned with operational impacts have a meaningful conversation here. And maybe, you should check out some of the upstream bug reports re. systemd interactions with NTP. Plonk. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Thu Oct 23 02:11:32 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Oct 2014 22:11:32 -0400 Subject: Self destruction in open source systems (was Re: Linux: concerns over systemd [OT]) In-Reply-To: References: <201410221052.s9MAqBZt096450@aurora.sol.net> <544844B7.5050900@cox.net> Message-ID: <544863D4.1010406@meetinghouse.net> Joe Hamelin wrote: > On Wed, Oct 22, 2014 at 4:58 PM, Larry Sheldon wrote: > >> Now I have Thunderbird and Firefox--from people who are committed to the >> notion that if it works, it must be replaced. If people like it, it must >> be redesigned. If it is stable, it must be updated. If there is a >> useless, senseless "feature" somewhere in the world, these products must be >> revised to make that feature the focus. > > And where is my new 1967 VW Microbus? That's all you need if you compile > it with --add-heater-fan. So I had to upgrade to a 1998 Volvo V70 wagon. > Don't know where I'm going to get a new one when this one wears out. Well hey, nobody's made a good 4WD station wagon since Toyota stopped making them. At one point it seemed like every 3rd person in the BBN parking lot had one, and we all drove them into the ground for lack of a replacement. Sigh... -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From Valdis.Kletnieks at vt.edu Thu Oct 23 02:18:45 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 22 Oct 2014 22:18:45 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Your message of "Wed, 22 Oct 2014 20:45:01 -0500." References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> Message-ID: <41894.1414030725@turing-police.cc.vt.edu> On Wed, 22 Oct 2014 20:45:01 -0500, Jeffrey Ollie said: > As I've already said a couple of times, systemd does not force a > particular NTP implementation on you. It comes with one (timedated), > and has a utility to manage it (timedatectl) but the admin can install > and use a different one if they like. Yeah, and if you want anything else to integrate in with systemd other than the supplied SNTP, you can pretty much go pound sand, according to Marcel Holtmann: "So this means that you get a really good basis where clocks are synchronized. If you want something better, you can install it. It is a waste of time trying to integrate anything else than timesyncd since if you use anything else, you will manually configure it and use its advanced options. If you do not need the advanced features, then why install other NTP clients in the first place." http://lists.freedesktop.org/archives/systemd-devel/2014-August/022572.html You should read the whole thread at freedesktop - it's pretty obvious that there's a really heavy bias towards "we have a solution that's good for desktops, and if you have a different use case, go pound sand". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jeff at ocjtech.us Thu Oct 23 02:47:46 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 21:47:46 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54486322.7020005@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> Message-ID: On Wed, Oct 22, 2014 at 9:08 PM, Miles Fidelman wrote: > Hey... how about not using selective editing to change the thread of > discussion (see below) > > If you're going to simply keep repeating "I like systemd, everything is > copacetic" - maybe you should take your fanboy attitude elsewhere, and let > those of us concerned with operational impacts have a meaningful > conversation here. Sigh, this is *exactly* why I should have stayed out of this. I hadn't seen much in terms of meaningful conversation before I posted, just a lot of hand-wringing about the doom about to happen. The arguments against systemd that I've seen so far: 1) It's different so it's bad. 2) There's a lot of code, there must be some really bad security problems just waiting to happen, so it's bad. 3) It doesn't do things the way we've always done them, so it's bad. 4) The systemd developers are jerks, so it's bad. > And maybe, you should check out some of the upstream bug > reports re. systemd interactions with NTP. While I don't have infinite amounts of time to read every mailing list thread or bug report, I have seen quite a few of them. And I think that a lot of the time, people are forgetting that it's difficult in email/textual communication to convey emotional subtlety and that can easily cause problems. > Plonk. Have fun in your nice quiet world where no one disagrees with you. -- Jeff Ollie From mysidia at gmail.com Thu Oct 23 02:48:51 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 22 Oct 2014 21:48:51 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <21575.63462.45782.746718@world.std.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein wrote: [snip] > The unix community has exerted great amounts of effort over the > decades to speed up reboot, particularly after crashes but also > planned. Perhaps you don't remember the days when an fsck was > basically mandatory and could take 15-20 minutes on a large disk. > > Then we added the clean bit (disk unmounted cleanly, no need for [snip] > And you whisk all that away with "it's not really clear to me that > 'reboots in seconds' is a think to be optimized"???? False dilemma. Optimizing reboot time down from 20 minutes to 1 minute is a significantly meaningful improvement; it's literally a 85% reduction in time spent during each boot process from the original time. Reducing boot time from 20 minutes to 10 seconds is not significantly better than reducing it to 1 minute. A different choice of tradeoffs is more appropriate to different kinds of systems, depending on their use case (Desktop vs Server)! Especially, when the method of reduction is subject to diminishing returns and increasing fragility or increasing complexity -- greater risk that something is breaking or more potential for unreliability is introduced into the startup process. Also, you may very well spend more time booting your system in order to troubleshoot, the fact that some applications are starting up in an unexpected order resulting in some issue. > To me that's like saying it's not important to try to design so one > can recover from a network outage in seconds. If you need to ensure that a service is not disrupted for more than seconds, then reboot is not the answer. It is some form of clustering. Reboot as a troubleshooting procedure is for desktops. 10 seconds from power on to user interface for desktops, will meaningfully improve the user experience, but not for servers. For servers, you ideally want to take the misbehaving node out of service and let its failover partner takeover. -- -JH From jeff at ocjtech.us Thu Oct 23 03:05:30 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 22:05:30 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <41894.1414030725@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <41894.1414030725@turing-police.cc.vt.edu> Message-ID: On Wed, Oct 22, 2014 at 9:18 PM, wrote: > On Wed, 22 Oct 2014 20:45:01 -0500, Jeffrey Ollie said: > >> As I've already said a couple of times, systemd does not force a >> particular NTP implementation on you. It comes with one (timedated), >> and has a utility to manage it (timedatectl) but the admin can install >> and use a different one if they like. > > Yeah, and if you want anything else to integrate in with systemd other than the > supplied SNTP, you can pretty much go pound sand, according to Marcel Holtmann: > > "So this means that you get a really good basis where clocks are synchronized. > If you want something better, you can install it. It is a waste of time trying > to integrate anything else than timesyncd since if you use anything else, you > will manually configure it and use its advanced options. If you do not need the > advanced features, then why install other NTP clients in the first place." > > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022572.html > > You should read the whole thread at freedesktop - it's pretty obvious that > there's a really heavy bias towards "we have a solution that's good for > desktops, and if you have a different use case, go pound sand". Yes, I've read the thread, and I think "go pound sand" is an unfair characterization of what *I* saw in that thread. To achieve the level of integration that timedated has with the rest of systemd would require more than just putting code into timedatectl to write out /etc/ntpd.conf and starting a service. timedated talks to networkd (that DHCP server that everyone is hating on as well) in real-time to determine the state of the network and to get any NTP servers that were sent in DHCP packets. To do that for chronyd or ntpd in the same way would require code changes and the systemd developers didn't want to do the work, as far as I know no one else has done the work, and I'm skeptical of the chances that such patches would get accepted upstream. So, if you want/need to run chronyd or ntpd you can, it'll "integrate" into the system just like any other service would, and you'll be no better/worse off than before timedated came into existence. -- Jeff Ollie From simon at darkmere.gen.nz Thu Oct 23 03:20:38 2014 From: simon at darkmere.gen.nz (Simon Lyall) Date: Thu, 23 Oct 2014 16:20:38 +1300 (NZDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <54486322.7020005@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> Message-ID: On Wed, 22 Oct 2014, Miles Fidelman wrote: > And maybe, you should check out some of the upstream bug reports re. > systemd interactions with NTP. If you think the current situation is all good then maybe you should look at other bugs for ntp. eg this one I that affected me with Ubuntu Disktop. They only run time syncing when the network is bounced so if you have a stable network then your machine will never sync: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933 Note that the importance of this has been set to "wishlist". -- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar From jeff at ocjtech.us Thu Oct 23 03:34:58 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 22 Oct 2014 22:34:58 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: On Wed, Oct 22, 2014 at 9:48 PM, Jimmy Hess wrote: > On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein wrote: >> And you whisk all that away with "it's not really clear to me that >> 'reboots in seconds' is a think to be optimized"???? > > False dilemma. > [ snip ] > 10 seconds from power on to user interface for desktops, will > meaningfully improve the user experience, but not for servers. It's a false dilemma only if you're thinking about traditional physical servers. Consider: 1) What if you're spinning up several thousand Hadoop nodes on AWS or GCE so that you can do some sort of "big data" operation. 2) What if PewDiePie just mentioned one of your products in a video and you need to quickly scale up the number of backend servers to handle the load. I'm sure that there are many other scenarios that I could devise where a fast "server" boot time was important. -- Jeff Ollie From jim at reptiles.org Thu Oct 23 04:02:29 2014 From: jim at reptiles.org (Jim Mercer) Date: Thu, 23 Oct 2014 00:02:29 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: <20141023040229.GA76956@reptiles.org> On Wed, Oct 22, 2014 at 09:48:51PM -0500, Jimmy Hess wrote: > Optimizing reboot time down from 20 minutes to 1 minute is a > significantly meaningful improvement; it's literally a 85% reduction > in time spent during each boot process from the original time. if reducing boot time from 20 minutes down to 1 minute, in a server environment, is a serious issue for you, maybe you should be looking at why you need to reboot so often? i'm somewhat puzzled by the fanboi mantra of "i've been running whizzy weasel and have 1574 days of uptime", which has now been supplanted by "geez, i have to wait 3 minutes every time i reboot this thing". running ntp, dhcp, dns, smtp, imap, http, that's what we do in serverland. and in addition to that, we need to run whatever the latest and greatest piece of crap that's being touted on slashdot (redis, mongo, couchbase, elasticsearch, anything that uses ruby/forever). we generally don't have alot of say in what we have to run because the fanboi's run the media, and management tends to give media more credence than the decades of experience they have in-house. that's how linux made it into the server environment in the first place. systemd sounds like a really useful thing if you are running a desktop system. as far as booting up a server, to run services, and to keep those services running, the init.d/rc.d/etc systems do a good job, and its generally not that hard to add/modify if you are half-assed competent. before criticizing people for being afraid of new technology, make sure that you yourself are not afraid of existing technology. --jim -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From javier at advancedmachines.us Thu Oct 23 04:18:45 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 23 Oct 2014 00:18:45 -0400 Subject: NTT high packet loss from US and BR to AU? Message-ID: Anyone else notice this? Or is this an AWS issue in APAC that hasn't been reported yet? AU-NY(aws) 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% BR(aws)-AU(aws) 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% NJ/NYC to AU(aws) 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0 From larrysheldon at cox.net Thu Oct 23 04:29:22 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 22 Oct 2014 23:29:22 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <6U4s1p00Q1cZc5601U4ttz> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <6U4s1p00Q1cZc5601U4ttz> Message-ID: <54488422.8020902@cox.net> On 10/22/2014 23:02, Jim Mercer wrote: > if reducing boot time from 20 minutes down to 1 minute, in a server environment, > is a serious issue for you, maybe you should be looking at why you need to > reboot so often? That is the question I have been asking myself. Back in the day we took it a a failure if a reboot happened. (I remember discussions about needing to reboot to keep counters from overflowing. I thought programming for counter wrap was a better idea.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From javier at advancedmachines.us Thu Oct 23 04:35:38 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 23 Oct 2014 00:35:38 -0400 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: On Thu, Oct 23, 2014 at 12:34 AM, Javier J wrote: > from Newark, NJ > > 1. pfsense.home 0.0% 295 > 0.2 0.1 0.1 0.7 0.0 > 2. l100.nwrknj-vfttp-134.verizon-gni.net 0.0% 294 > 1.1 8.7 0.9 297.7 31.3 > 3. g0-14-4-1.nwrknj-lcr-21.verizon-gni.net 0.0% 294 > 1.9 4.1 1.6 21.2 2.0 > 4. ae3-0.nwrk-bb-rtr1.verizon-gni.net 0.0% 294 > 30.6 13.3 1.6 127.7 22.0 > 5. ??? > 6. 0.ae1.br3.nyc4.alter.net 0.0% 294 > 22.1 5.0 4.6 36.0 2.2 > 7. 204.255.169.234 0.0% 294 > 3.3 4.0 2.9 221.6 12.7 > 8. ae-2.r23.nycmny01.us.bb.gin.ntt.net 2.4% 294 > 8.9 7.0 3.4 33.8 6.2 > 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 47.3% 294 > 9.6 16.7 9.2 35.8 6.5 > 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 0.0% 294 > 71.5 72.2 71.3 91.8 1.9 > 11. xe-0-0-0.r02.lsanca03.us.bb.gin.ntt.net 5.1% 294 > 68.5 69.4 68.0 106.7 4.8 > 12. as-1.r05.sydnau01.au.bb.gin.ntt.net 13.6% 294 > 292.2 289.8 280.8 313.7 3.5 > 13. xe-0-1-0.a06.sydnau01.au.ra.gin.ntt.net 11.2% 294 > 288.5 290.3 281.5 348.9 5.5 > 14. 202.68.70.10 9.5% 294 > 294.3 289.7 280.6 308.9 3.3 > 15. 54.240.192.89 10.6% 294 > 291.4 288.7 279.5 299.8 3.2 > 16. 54.240.192.113 10.9% 294 > 290.1 287.5 279.2 298.7 3.0 > 17. 54.240.192.171 11.9% 294 > 296.2 291.4 282.1 299.1 3.1 > 18. 54.240.192.160 11.3% 294 > 296.2 292.2 283.9 299.6 3.2 > 19. s3-website-ap-southeast-2.amazonaws.com 15.4% 294 > 292.1 291.6 281.9 299.0 3.0 > > From AWS brazil. > > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. ec2-177-71-128-6.sa-east-1.compute.amazonaws.com > 0.0% 1364 0.6 0.8 0.5 41.3 3.1 > 2. 177.72.240.152 > 0.0% 1364 0.9 1.2 0.7 50.6 3.6 > 3. 177.72.240.134 > 2.8% 1364 1.0 1.2 0.7 23.1 2.4 > 4. 2-2-0-0-IPV4-GRASAOTM1 > 0.0% 1364 1.5 0.9 0.6 34.3 2.7 > 5. 5.53.5.246 > 0.0% 1364 1.6 9.7 1.3 117.4 21.1 > 6. Xe2-0-2-0-grtmiana2.red.telefonica-wholesale.net > 0.0% 1364 117.4 119.5 117.1 134.5 3.5 > TE-0-5-0-3-GRTMIANA4.red.telefonica-wholesale.net > Xe2-0-0-0-grtmiana2.red.telefonica-wholesale.net > 7. Xe2-1-3-0-grtmiabr4.red.telefonica-wholesale.net > 0.0% 1364 119.4 127.9 119.0 304.6 22.1 > Te0-10-0-6-grtmiabr6.red.telefonica-wholesale.net > 8. Xe0-0-0-0-grtpaopx2.red.telefonica-wholesale.net > 0.0% 1364 181.9 184.2 181.8 250.1 8.0 > Xe1-3-0-0-grtpaopx2.red.telefonica-wholesale.net > 9. 213.140.53.178 > 0.0% 1364 182.8 182.5 181.9 185.8 0.7 > 10. ae-15.r01.snjsca04.us.bb.gin.ntt.net > 0.8% 1364 525.1 535.6 497.8 546.8 6.1 > 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net > 52.1% 1364 200.8 192.8 180.5 214.9 9.3 > 12. ae-7.r21.lsanca03.us.bb.gin.ntt.net > 0.3% 1364 183.5 184.4 182.5 263.8 6.1 > 13. xe-0-0-0.r02.lsanca03.us.bb.gin.ntt.net > 2.5% 1364 183.9 183.8 182.5 224.1 4.4 > 14. as-3.r05.sydnau01.au.bb.gin.ntt.net > 3.2% 1364 546.5 544.3 520.7 642.3 8.0 > 15. xe-0-1-0.a06.sydnau01.au.ra.gin.ntt.net > 1.7% 1364 538.6 542.2 514.5 653.1 8.3 > 16. 202.68.70.10 > 2.3% 1364 411.3 413.8 384.3 445.4 3.5 > 17. 54.240.192.93 > 2.5% 1364 406.3 411.9 387.9 420.2 2.7 > 18. 54.240.192.117 > 2.2% 1363 405.5 412.5 394.0 482.0 6.6 > 19. 54.240.192.193 > 2.8% 1363 406.7 410.6 396.2 420.2 2.4 > 20. s3-website-ap-southeast-2.amazonaws.com > 2.6% 1363 407.6 410.5 397.2 415.7 2.4 > > > From an AWS instance in Sydney to 4.2.2.2 > > 1. ip-10-5-69-193.ap-southeast-2.co 0.0% 1545 0.8 5.3 0.6 180.5 > 17.3 > 2. 100.68.201.6 0.0% 1545 0.5 0.4 0.3 44.0 > 1.4 > 3. 100.68.201.46 0.0% 1545 0.4 0.3 0.3 28.9 > 0.9 > 4. 100.67.186.7 0.0% 1545 0.4 0.3 0.3 38.9 > 1.2 > 5. 100.67.185.242 0.0% 1545 1.2 0.8 0.6 2.7 > 0.3 > 6. 100.64.135.177 0.0% 1545 0.8 0.8 0.7 3.0 > 0.3 > 7. 100.64.128.240 0.0% 1545 1.0 0.8 0.6 2.6 > 0.3 > 8. 100.64.57.50 0.0% 1545 0.4 0.7 0.3 148.8 > 7.3 > 9. 100.64.24.133 0.0% 1544 1.1 0.9 0.7 3.6 > 0.4 > 10. ec2-54-252-0-16.ap-southeast-2.c 0.0% 1544 0.6 0.8 0.2 52.6 > 4.7 > 11. 54.240.192.108 0.0% 1544 2.2 2.0 1.9 9.4 > 0.6 > 12. 54.240.192.78 0.0% 1544 3.4 3.2 1.9 18.3 > 1.1 > 13. 202.68.70.5 0.0% 1544 1.7 2.5 1.3 95.3 > 8.1 > 14. xe-5-1-0.r05.sydnau01.au.bb.gin. 0.0% 1544 1.5 1.6 1.4 37.1 > 2.4 > 15. as-2.r02.lsanca03.us.bb.gin.ntt. 0.0% 1544 139.5 220.2 139.2 283.5 > 7.8 > 16. xe-2-1-9.r20.lsanca03.us.bb.gin. 2.1% 1544 232.5 226.2 155.4 255.0 > 5.7 > xe-0-0-7.r21.lsanca03.us.bb.gin.ntt.net > 17. ae-2.r04.lsanca03.us.bb.gin.ntt. 1.4% 1544 231.6 225.9 174.8 233.0 > 5.0 > ae-1.r04.lsanca03.us.bb.gin.ntt.net > 18. xe-1.level3.lsanca03.us.bb.gin.n 80.8% 1544 144.6 170.4 143.7 193.4 > 3.6 > xe-2.level3.lsanca03.us.bb.gin.ntt.net > xe-3.level3.lsanca03.us.bb.gin.ntt.net > xe-0.level3.lsanca03.us.bb.gin.ntt.net > 19. b.resolvers.Level3.net 81.6% 1544 149.3 178.4 148.3 183.2 > 4.5 > > > On Thu, Oct 23, 2014 at 12:28 AM, Charles van Niman > wrote: > >> Howdy all, >> >> I've been lurking for a long time, first time writing in. Please >> excuse my inexperience. Javier, can you provide full traces, and >> source/destination addresses? >> >> /Charles >> >> On Wed, Oct 22, 2014 at 11:18 PM, Javier J >> wrote: >> >>> Anyone else notice this? >>> >>> Or is this an AWS issue in APAC that hasn't been reported yet? >>> >>> AU-NY(aws) >>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% >>> >>> BR(aws)-AU(aws) >>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% >>> >>> >>> NJ/NYC to AU(aws) >>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 >>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 >>> 9.0 >>> >> >> > From contact at winterei.se Thu Oct 23 04:35:34 2014 From: contact at winterei.se (Paul S.) Date: Thu, 23 Oct 2014 13:35:34 +0900 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: <54488596.2080506@winterei.se> Does it actually persist to your destination? Loss in transit paths is simply ICMP de-prioritization unless it's losing packets all the way to the last hop. On 10/23/2014 午後 01:18, Javier J wrote: > Anyone else notice this? > > Or is this an AWS issue in APAC that hasn't been reported yet? > > AU-NY(aws) > 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% > > BR(aws)-AU(aws) > 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% > > > NJ/NYC to AU(aws) > 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 > 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0 From streiner at cluebyfour.org Thu Oct 23 04:41:56 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 23 Oct 2014 00:41:56 -0400 (EDT) Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: Do you see any other indications of performance problems? jms On Thu, 23 Oct 2014, Javier J wrote: > Anyone else notice this? > > Or is this an AWS issue in APAC that hasn't been reported yet? > > AU-NY(aws) > 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% > > BR(aws)-AU(aws) > 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% > > > NJ/NYC to AU(aws) > 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 > 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0 > From javier at advancedmachines.us Thu Oct 23 04:54:53 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 23 Oct 2014 00:54:53 -0400 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: So we have a nagios box in the environment in Sydney and everything is 100% ok. new relic kept loosing connectivity to 30 plus servers on and off. Guys from California can ssh in, some cant. AWS reports everything operating as normal. Guys from other parts of the world can and can't load web pages. All servers show low usage (if you can ssh to them) It seems to be getting better now but still not right. This is from a box in AWS(sys) to level 3 dns server. --- 4.2.2.2 ping statistics --- 70 packets transmitted, 68 received, 2% packet loss, time 69744ms rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms [root at Webapp javier]# Before it was 70% packet lost to that host. There is a mtr traceroute in a previous email. Look for AU-US On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner < streiner at cluebyfour.org> wrote: > Do you see any other indications of performance problems? > > jms > > > On Thu, 23 Oct 2014, Javier J wrote: > > Anyone else notice this? >> >> Or is this an AWS issue in APAC that hasn't been reported yet? >> >> AU-NY(aws) >> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% >> >> BR(aws)-AU(aws) >> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% >> >> >> NJ/NYC to AU(aws) >> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 >> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 >> 9.0 >> >> From simon at darkmere.gen.nz Thu Oct 23 05:11:50 2014 From: simon at darkmere.gen.nz (Simon Lyall) Date: Thu, 23 Oct 2014 18:11:50 +1300 (NZDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: <54488422.8020902@cox.net> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <6U4s1p00Q1cZc5601U4ttz> <54488422.8020902@cox.net> Message-ID: On Wed, 22 Oct 2014, Larry Sheldon wrote: > That is the question I have been asking myself. > > Back in the day we took it a a failure if a reboot happened. (I remember > discussions about needing to reboot to keep counters from overflowing. I > thought programming for counter wrap was a better idea.) When I see a machine with a long uptime I ask myself: 1. When was the last kernel update? 2. Do we know it would come back cleanly when it is rebooted? 3. What would happen to the site if that machine went offline? -- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar From andree+nanog at toonk.nl Thu Oct 23 05:25:11 2014 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 22 Oct 2014 22:25:11 -0700 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: <54489137.4080700@toonk.nl> Yup seeing the same. Following examples all show same loss pattern between ~ 3:30 and ~ 4:30 UTC: syd ntt - nyc ntt syd ntt - mia ntt syd ntt - cdg ntt (paris) syd ntt - ams ntt One example: http://i.imgur.com/TmCkd1B.png?1 Cheers, Andree .-- My secret spy satellite informs me that at 2014-10-22 9:54 PM Javier J wrote: > So we have a nagios box in the environment in Sydney and everything is 100% > ok. > > new relic kept loosing connectivity to 30 plus servers on and off. > > Guys from California can ssh in, some cant. > > AWS reports everything operating as normal. > > Guys from other parts of the world can and can't load web pages. > > All servers show low usage (if you can ssh to them) > > It seems to be getting better now but still not right. > > This is from a box in AWS(sys) to level 3 dns server. > > --- 4.2.2.2 ping statistics --- > 70 packets transmitted, 68 received, 2% packet loss, time 69744ms > rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms > [root at Webapp javier]# > > Before it was 70% packet lost to that host. There is a mtr traceroute in a > previous email. Look for AU-US > > > > On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner < > streiner at cluebyfour.org> wrote: > >> Do you see any other indications of performance problems? >> >> jms >> >> >> On Thu, 23 Oct 2014, Javier J wrote: >> >> Anyone else notice this? >>> Or is this an AWS issue in APAC that hasn't been reported yet? >>> >>> AU-NY(aws) >>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% >>> >>> BR(aws)-AU(aws) >>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% >>> >>> >>> NJ/NYC to AU(aws) >>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 >>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 >>> 9.0 >>> >>> > From george.herbert at gmail.com Thu Oct 23 05:28:01 2014 From: george.herbert at gmail.com (George Herbert) Date: Wed, 22 Oct 2014 22:28:01 -0700 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <6U4s1p00Q1cZc5601U4ttz> <54488422.8020902@cox.net> Message-ID: <20FF6E1A-D8A0-4B61-BAE0-3150244565B6@gmail.com> Ok. As a highly on- list-topic example of why distrust is called for... Without referring to the systemd source code*, does anyone know what systemd uses to select between networking subsystems (i.e. NetworkManager, the new standard as of RHEL 7, vs /etc/ sysconfig/network-scripts/, etc.). NetworkManager is default but disableable and it magically falls back to network-scripts dir, but the fallback is nearly undocumented and the selection behavior appears completely undocumented. If by some chance you do know this, where did you come by that knowledge? Hopefully with URLs. (* don't bother telling me to read the source. I'm reading...) If I cannot find credible documentation of this, as networking person as well as enterprise sysadmin, this is a Problem.) George William Herbert Sent from my iPhone From javier at advancedmachines.us Thu Oct 23 05:31:45 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 23 Oct 2014 01:31:45 -0400 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: <54489137.4080700@toonk.nl> References: <54489137.4080700@toonk.nl> Message-ID: Thank you Andree, This confirms it wasn't just us. I am curious if anyone knows what the issue was. I can't find anything on NTT website. On Thu, Oct 23, 2014 at 1:25 AM, Andree Toonk wrote: > Yup seeing the same. Following examples all show same loss pattern > between ~ 3:30 and ~ 4:30 UTC: > > syd ntt - nyc ntt > syd ntt - mia ntt > syd ntt - cdg ntt (paris) > syd ntt - ams ntt > > One example: > http://i.imgur.com/TmCkd1B.png?1 > > Cheers, > Andree > > > > .-- My secret spy satellite informs me that at 2014-10-22 9:54 PM > Javier J wrote: > > So we have a nagios box in the environment in Sydney and everything is > 100% > > ok. > > > > new relic kept loosing connectivity to 30 plus servers on and off. > > > > Guys from California can ssh in, some cant. > > > > AWS reports everything operating as normal. > > > > Guys from other parts of the world can and can't load web pages. > > > > All servers show low usage (if you can ssh to them) > > > > It seems to be getting better now but still not right. > > > > This is from a box in AWS(sys) to level 3 dns server. > > > > --- 4.2.2.2 ping statistics --- > > 70 packets transmitted, 68 received, 2% packet loss, time 69744ms > > rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms > > [root at Webapp javier]# > > > > Before it was 70% packet lost to that host. There is a mtr traceroute in > a > > previous email. Look for AU-US > > > > > > > > On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner < > > streiner at cluebyfour.org> wrote: > > > >> Do you see any other indications of performance problems? > >> > >> jms > >> > >> > >> On Thu, 23 Oct 2014, Javier J wrote: > >> > >> Anyone else notice this? > >>> Or is this an AWS issue in APAC that hasn't been reported yet? > >>> > >>> AU-NY(aws) > >>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% > >>> > >>> BR(aws)-AU(aws) > >>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% > >>> > >>> > >>> NJ/NYC to AU(aws) > >>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 > 13.3 > >>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 > >>> 9.0 > >>> > >>> > > > From joelja at bogus.com Thu Oct 23 05:39:40 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 22 Oct 2014 22:39:40 -0700 Subject: Linux: concerns over systemd [OT] In-Reply-To: <54488422.8020902@cox.net> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <6U4s1p00Q1cZc5601U4ttz> <54488422.8020902@cox.net> Message-ID: <5448949C.1030709@bogus.com> On 10/22/14 9:29 PM, Larry Sheldon wrote: > On 10/22/2014 23:02, Jim Mercer wrote: > >> if reducing boot time from 20 minutes down to 1 minute, in a server >> environment, >> is a serious issue for you, maybe you should be looking at why you >> need to >> reboot so often? > > > That is the question I have been asking myself. > > Back in the day we took it a a failure if a reboot happened. (I > remember discussions about needing to reboot to keep counters from > overflowing. I thought programming for counter wrap was a better idea.) Back over here in router-land when the cat65k vss pair went down it's at least 20 minutes before it's back. If you enjoy what may be the longest minutes of your life try tripping over a bug that takes out two pairs and a whole pop. Having something come back quickly is part of having flexibility since things do go pear-shaped, and responding to outages rather than not having them is not tick box we get to decline. Today my Arista reloada in about 220 seconds which is tolerable but if it were half that I'd be even happier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From list at satchell.net Thu Oct 23 06:51:18 2014 From: list at satchell.net (Stephen Satchell) Date: Wed, 22 Oct 2014 23:51:18 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> Message-ID: <5448A566.3060700@satchell.net> On 10/22/2014 08:20 PM, Simon Lyall wrote: > On Wed, 22 Oct 2014, Miles Fidelman wrote: >> And maybe, you should check out some of the upstream bug reports re. >> systemd interactions with NTP. > > If you think the current situation is all good then maybe you should > look at other bugs for ntp. eg this one I that affected me with Ubuntu > Disktop. They only run time syncing when the network is bounced so if > you have a stable network then your machine will never sync: > > https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933 > > Note that the importance of this has been set to "wishlist". > Looking at the ticket you submitted, I see this statement: > On Ubuntu 12.04 desktop, in System Settings > Time & Date, when the > time is set to update Automatically from Internet it syncs once but > then drifts out over a period of days. > > In Syslog I can see that ntpdate is called on boot but is never called again. I'm a long-time user of NTP, and what you are asking for is a no-good way of doing things. What you are supposed to do is use the ntpdate(8) utility *ONCE* on boot to initially set the system clock, then you have ntpd(8) running to do two things for you: sync up to one or more time sources, and discipline the local clock. What is "discipline the local clock?" This is the process of determining the *exact* frequency of the crystal clock in your local computer, and tuning your local clock hardware so that local real time is in sync with the world. This is because the accuracy of the crystal is specified to be rather loose (hundreds of parts per million), but the relative accuracy of a crystal is actually within tens of parts or even single-digit parts per million. So if you can measure the drift, you can in software compensate for it so you get a true-chimer. That's what the ntpd daemon does. Now, what is supposed to start the ntpd daemon in Ubuntu? DHCP has no significant effects on the filters used in ntpd(8). I didn't have any problem getting this to work "the right way" on Slackware, Red Hat, and Debian. It works "out of the box" with Fedora and CentOS, to the point that I don't even think much about it other than in the GUI to point to my local time source on system install. It even works with the Ubuntu 8.04.4 LTS server that was forced down my throat a few years back, which I'm in the process of trying to retire in favor of a CentOS 6.5 server implementation. (At least THAT Ubuntu-loving sysadmin is gone now.) What happens on your box when you do "/etc/init.d/ntp start"? And how frequently do you reboot your box? It sounds like it's up all the time, which means the local clock can be trimmed very accurately indeed. That's the SERVER way of running a time synchronization. So it would appear that you have a quarrel with GUI support, not with NTP itself. From jeff at ocjtech.us Thu Oct 23 06:55:40 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 23 Oct 2014 01:55:40 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <20FF6E1A-D8A0-4B61-BAE0-3150244565B6@gmail.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <54488422.8020902@cox.net> <20FF6E1A-D8A0-4B61-BAE0-3150244565B6@gmail.com> Message-ID: On Thu, Oct 23, 2014 at 12:28 AM, George Herbert wrote: > > Ok. As a highly on- list-topic example of why distrust is called for... > > Without referring to the systemd source code*, does anyone know what systemd uses to select between networking subsystems (i.e. NetworkManager, the new standard as of RHEL 7, vs /etc/ sysconfig/network-scripts/, etc.). NetworkManager is default but disableable and it magically falls back to network-scripts dir, but the fallback is nearly undocumented and the selection behavior appears completely undocumented. systemctl status NetworkManager.service systemctl status network.service I don't think that there's anything magic about it, you have one or the other enabled. Adding NM_CONTROLLED=yes/no to /etc/sysconfig/network-scripts/ifcfg-* gives you per-interface control over whether NetworkManager or the network scripts are used for managing the interface. If neither is enabled you probably end up with no networking. > If by some chance you do know this, where did you come by that knowledge? Hopefully with URLs. I have access to systems that run systemd and I tried a couple of things... Also, I've been managing Red Hat systems for a long time and have known about this for a while. But a little bit of googling and I found this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-NetworkManager_and_the_Network_Scripts.html Unless you're running systemd-networkd, this is really distro-specific stuff as I expect that most distros will want to preserve some backward compatibility with "legacy" network configuration. -- Jeff Ollie From jwbensley at gmail.com Thu Oct 23 08:43:51 2014 From: jwbensley at gmail.com (James Bensley) Date: Thu, 23 Oct 2014 09:43:51 +0100 Subject: Jared Mauch In-Reply-To: References: <5447249D.5030301@cox.net> Message-ID: Congratulations Jared and well done with the hard work :) Cheers, James. From srahul.in at gmail.com Thu Oct 23 08:48:57 2014 From: srahul.in at gmail.com (Rahul Sawarkar) Date: Thu, 23 Oct 2014 14:18:57 +0530 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: Systemd Blackhole is a very apt term as I am discovering. I was once a linuxfromscratch "superuser" 10 years back, in a sense that if anyone asked me the location of a lib.so and how to resolve a version mismatch, I could fix it in a matter of minutes even if woken up at 4am in the morning. Likewise for almost any other complex debugging challenge. Take it with a pinch of salt though - it is more a statement of my confidence in my own abilities then, than something absolute and ahistorical. I have since downgraded to being a mere power user over the years who just wants to get the job done with the focus being my objective as an end-user. Right now I am having difficulty auto mounting an NFS partition at boot from /etc/fstab, and systemd isn't telling me if it even attempted to and why it failed. Google and wiki isn't helping either. No log line ...absolutely nothing. A manual "mount -a" works flawlessly. In the older days I would read a log line and navigate to the init script if I had to, read and understand the sequencing and dependencies and learn to fix things. Right now I am clueless and helpless. My confidence about fixing problems on a Linux with systemd is very low. I am reduced to being a Googler searching for answers in the unknown rather than upgrade my skills level back to where I was earlier. I am glad this topic came up and I discovered early enough that there now has to be a strategic choice and decision making I need to make in the Linux world that is not going to be a dead-end for me if I choose to go the init way - one that stays loyal to the original Unix philosophy. I am glad to hear there is a substantial movement and backing for this that might pave the way for a non -systemd alternative. I wonder what Mr. Linus Trovaldis himself thinks on this matter though. I am curious to find out. Rahul Sent from MiPad On Oct 22, 2014 1:18 AM, "Jim Popovitch" wrote: > On Tue, Oct 21, 2014 at 3:41 PM, Eugeniu Patrascu > wrote: > > > > I think systemd wants to become the next Emacs ;)) > > Or the next user activity collection point. Systemd really is a > black hole to 99.9% of the people who will use/deploy it... seems > perfect for lots of things. > > -Jim P. > From mpalmer at hezmatt.org Thu Oct 23 07:15:06 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 23 Oct 2014 18:15:06 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <41894.1414030725@turing-police.cc.vt.edu> Message-ID: <20141023071506.GK16429@hezmatt.org> On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jeffrey Ollie wrote: > To achieve the level of integration that timedated has with the rest > of systemd would require more than just putting code into timedatectl > to write out /etc/ntpd.conf and starting a service. timedated talks > to networkd (that > DHCP server that everyone is hating on as well) in real-time to > determine the state of the network and to get any NTP servers that > were sent in DHCP packets. To do that for chronyd or ntpd in the same > way would require code changes and the systemd developers didn't want > to do the work, This is the core problem with systemd, in my mind -- and what has gotten Linus, amongst other people, so thoroughly cheesed off with the systemd devs. They don't play well with other children. They don't appear particularly interested in reusing any existing code, because it's a lot more fun to write new code. I'm a strong proponent of Joel Spolsky's views on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the same problems will come to haunt systemd on its way from being the new kid on the block to being legacy code[1]. - Matt [1] A computer industry term which means, "it works". From david at mailplus.nl Thu Oct 23 09:02:30 2014 From: david at mailplus.nl (David Hofstee) Date: Thu, 23 Oct 2014 11:02:30 +0200 Subject: anyone from vodafone(.nl) around? Message-ID: <78C35D6C1A82D243B830523B4193CF5F75CAC05E9C@SBS1.blinker.local> Hi, Is anyone from Vodafone around? We are having connectivity loss with smtp.vodafone.nl and the helpdesk is not cooperating... David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) From robert at ripe.net Thu Oct 23 09:04:39 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 23 Oct 2014 11:04:39 +0200 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141023071506.GK16429@hezmatt.org> References: <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <41894.1414030725@turing-police.cc.vt.edu> <20141023071506.GK16429@hezmatt.org> Message-ID: <5448C4A7.6040706@ripe.net> On 2014-10-23 9:15, Matt Palmer wrote: > On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jeffrey Ollie wrote: >> To achieve the level of integration that timedated has with the rest >> of systemd would require more than just putting code into timedatectl >> to write out /etc/ntpd.conf and starting a service. timedated talks >> to networkd (that >> DHCP server that everyone is hating on as well) in real-time to >> determine the state of the network and to get any NTP servers that >> were sent in DHCP packets. To do that for chronyd or ntpd in the same >> way would require code changes and the systemd developers didn't want >> to do the work, > > This is the core problem with systemd, in my mind -- and what has gotten > Linus, amongst other people, so thoroughly cheesed off with the systemd > devs. They don't play well with other children. They don't appear > particularly interested in reusing any existing code, because it's a lot > more fun to write new code. I'm a strong proponent of Joel Spolsky's views > on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the http://www.joelonsoftware.com/articles/fog0000000069.html > same problems will come to haunt systemd on its way from being the new kid > on the block to being legacy code[1]. > > - Matt > > [1] A computer industry term which means, "it works". > > From zperes at kwikom.com Thu Oct 23 13:32:37 2014 From: zperes at kwikom.com (Zachery Peres) Date: Thu, 23 Oct 2014 08:32:37 -0500 Subject: Yahoo Postmaster Message-ID: <54490375.7040000@kwikom.com> Looking for a Yahoo Postmaster to contact me offlist. Thank You --Zach P. JMZ Corporation From seth.mos at dds.nl Thu Oct 23 13:42:45 2014 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 23 Oct 2014 15:42:45 +0200 Subject: anyone from vodafone(.nl) around? In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75CAC05E9C@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F75CAC05E9C@SBS1.blinker.local> Message-ID: <544905D5.4050109@dds.nl> David Hofstee schreef op 23-10-2014 11:02: > Hi, > > Is anyone from Vodafone around? We are having connectivity loss with smtp.vodafone.nl and the helpdesk is not cooperating... I've had good succes getting a out of date bogon filter issue for all Vodafone NL customers resolved after contacting the following address from the WHOIS information on bgp.he.net. nmc.nl at vodafone.com Kind regards, Seth From nanog at jack.fr.eu.org Thu Oct 23 13:44:29 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Thu, 23 Oct 2014 15:44:29 +0200 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5448949C.1030709@bogus.com> References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <6U4s1p00Q1cZc5601U4ttz> <54488422.8020902@cox.net> <5448949C.1030709@bogus.com> Message-ID: <5449063D.5020902@jack.fr.eu.org> When I'm talking about "hardware initialization", I'm talking about the huge part that appends *before* the kernel boots. For example, hard-based RAID. On my server, when I push the start button, bios start-up, do a lot of awesome things (irony), start the raid (sloowly), and then, after 5min, pop up grub, then Linux, etc. 5min for hard (from power-on to grub), 20sec for software (from grub to prompt) From jloiacon at csc.com Thu Oct 23 14:36:24 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 23 Oct 2014 10:36:24 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> Message-ID: "NANOG" wrote on 10/22/2014 10:47:46 PM: > The arguments against systemd that I've seen so far: > > 1) It's different so it's bad. > 2) There's a lot of code, there must be some really bad security > problems just waiting to happen, so it's bad. > 3) It doesn't do things the way we've always done them, so it's bad. > 4) The systemd developers are jerks, so it's bad. Hmmm. It seems that list is missing its most important item. As an impartial lurker, the primary objection I've seen is: 1. "Try to do everything" software is not optimal, and will lead to heartache. Joe From eraya at a21an.org Wed Oct 22 10:18:22 2014 From: eraya at a21an.org (Eray Aslan) Date: Wed, 22 Oct 2014 10:18:22 +0000 Subject: Linux: concerns over systemd [OT] In-Reply-To: <5446E560.8080501@ninjabadger.net> References: <13883941.6617.1413932156378.JavaMail.root@benjamin.baylink.com> <5446E560.8080501@ninjabadger.net> Message-ID: <20141022101822.GA15515@angelfall> On Tue, Oct 21, 2014 at 11:59:44PM +0100, Tom Hill wrote: > It's Gentoo: "You should write your own" is the most likely answer. Not if you ask nicely :) -- Eray Aslan From turmoil at privacyrequired.com Wed Oct 22 16:57:07 2014 From: turmoil at privacyrequired.com (*) Date: Wed, 22 Oct 2014 09:57:07 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> Message-ID: <5447E1E3.1010801@privacyrequired.com> On 10/21/2014 05:20 PM, Jimmy Hess wrote: > The all-in-one approach of systemd might have a place on some > specialized desktop distros, but outside that niche its' IMO a > terrible idea. > > The proper fix is probably a go back to Upstart or SysVInit and > rewrite systemd, so all the pieces are separated and exist as a > higher layer on top of init. That is how systemd works, there are many parts and "systemd" is the sum of all those parts. It has a PID1 that replaces sysvinit/upstart, but afaik it doesn't do a whole lot extra. I don't use systemd, and I don't know a lot about it, but it seems lots of people don't get that it's not all lumped in PID1, there are a lot of processes that do different things that are mostly tightly held together (I think only udev and a couple other things still work without the rest of systemd.) Then again, the systemd people do spread FUD about sysvinit as well, Poettering's own blog for example even misleads on how systemd and sysvinit work http://0pointer.de/blog/projects/why.html A lot of things in the comparison chart have sysvinit listed as "no", when it's obviously not init's job directly, but a subprocess/script, except it lists "yes" for systemd on some, where systemd still passes it off to a subprocess! (They really are taking advantage of the PID1 and the entire bundle of software both being named "systemd" I guess.) [Insert obligatory "No I don't think sysvinit is perfect, but..." here] ps. What's with all the fear/hate of shell scripts? I realize the init scripts on most Linux distros are messy (200 LOC just to start sshd? Come on debian.) but the solution isn't to run away from them; rewrite scripts to have saner logic and not do a dozen redundant/unnecessary checks. From Jlawrence at anchorfree.com Wed Oct 22 19:30:30 2014 From: Jlawrence at anchorfree.com (Jamie Lawrence) Date: Wed, 22 Oct 2014 19:30:30 +0000 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: On 10/22/14, 9:01 AM, "Jeffrey Ollie" wrote: >Bull. If you've been around the FOSS community even for a short >while, you'd know that systemd has become a religious topic akin to On 10/22/14, 10:41 AM, "Jeffrey Ollie" wrote: >sums up my thoughts on the "unix philosophy". It's not the >be-all-end-all that you make it out to be. Again, this sounds a lot >like "Grumpy Old Man" complaining. You appear to be the only one here having difficulties being civil on the topic. The rest of us are having an interesting, pleasant discussion about a rather huge operational shift. You like systemd. Great. More power to you. You apparently don’t like it that many others have differing views or are still reserving judgment. Also great, you can ignore the thread. That said, my take on the mess. I need to see systemd running for while in large-scale production before I’m moving anything to it. I do rather hate the NIH-itis, the svchost.exe-ish nature of the technical approach, the core devs' attitudes, the tightly-coupled nature of the approach to doing the various things it wants to do, and the devs' stated goal of forcing every linux distro in to using it. And fu’ing binary logs. OTOH, it does offer some nice things that can become annoying with other tools. The single-sourced APIs for userspace apps might be appreciated by some developers, especially refugees from MSFT-land. It is immature compared to the competition with a radically un-unix approach developed by people with a track record of being extremely difficult to collaborate with, and it does several specific things I really don’t like. That adds up to a hard sell for me. Some may see me as a "grumpy old man" for that. I see it as a technical conservatism for my production environments borne of having been burned by shiny-cool-new before one too many times, and a tired dislike of being paged out of bed over some chrome plated new hotness that crapped itself again. There is a deeper argument about "the unix way" here as well. I do see a lot of people become frustrated by what they see as impedance mismatched between tools as they learn ("why should I have to care about what the IFS is?"), or because a tool fails to react in accordance with their expectations, or because they are using the wrong tool ("I want to match these HTML tags with a regex..."), or because they realize a problem they thought should be easy, isn't. I think that’s natural, to some extent. I did (and still do, sometimes - there seems to be a hard limit on the number of awk implementation differences that fit in my brain, for instance). And there are things that could be made a lot better. But when I start wondering if my init system has a flight simulator easter egg, well, there’s a problem, at least for me. It is funny to see people use "but that approach is 40 years old!" on both sides of the argument. I do love playing with new toys, and think the systemd folks should write whatever they want. I have major issues with the monoculture they want to establish. (And yes, a core developer clearly stated that as a goal[1].) Most of my systems are Linux these days, and I am mostly distro-agnostic, although my default does happen to be Debian. I do think I’m going to have to get back up to speed on FreeBSD again. -j [1] https://lists.fedoraproject.org/pipermail/devel/2011-June/152672.html : "[...]we want to gently push the distros to standardize on the same components for the base system[...]" From gregory.boyce at gmail.com Wed Oct 22 21:37:45 2014 From: gregory.boyce at gmail.com (Gregory Boyce) Date: Wed, 22 Oct 2014 17:37:45 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <14836372.6627.1413939794775.JavaMail.root@benjamin.baylink.com> <34C0467D-21A2-4A58-B4AB-A5F7B60D105D@gmail.com> <54477BD2.10905@meetinghouse.net> <54480717.2030609@blue-labs.org> Message-ID: On Wed, Oct 22, 2014 at 5:28 PM, Gregory Boyce wrote: > On Wed, Oct 22, 2014 at 5:17 PM, Jeffrey Ollie wrote: >> I think that Debian's plan to allow multiple init systems >> (irregardless of which one is default) is a bad plan. The non-default >> ones won't get any love - at some point they'll just stop working (or >> indeed, work at all). > > If they break then one of two things will happen: > > 1) Someone will fix it. > > 2) No one will fix it because no one cares. If no one cares, then it > being broken doesn't matter. > > Killing off choice/alternatives just in case no one cares about them > isn't especially helpful. Resending since my subscription was apparently a bit off. -- Greg From charles at phukish.com Thu Oct 23 04:28:32 2014 From: charles at phukish.com (Charles van Niman) Date: Wed, 22 Oct 2014 23:28:32 -0500 Subject: NTT high packet loss from US and BR to AU? In-Reply-To: References: Message-ID: Howdy all, I've been lurking for a long time, first time writing in. Please excuse my inexperience. Javier, can you provide full traces, and source/destination addresses? /Charles On Wed, Oct 22, 2014 at 11:18 PM, Javier J wrote: > Anyone else notice this? > > Or is this an AWS issue in APAC that hasn't been reported yet? > > AU-NY(aws) > 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0% > > BR(aws)-AU(aws) > 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4% > > > NJ/NYC to AU(aws) > 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3 > 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0 > From amps at djlab.com Thu Oct 23 14:56:40 2014 From: amps at djlab.com (Randy) Date: Thu, 23 Oct 2014 10:56:40 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5445AD63.7090400@lugosys.com> References: <5445AD63.7090400@lugosys.com> Message-ID: I've enjoyed kernel hot patches (ksplice) until now. So my primary concern is that updates to systemd appears to require a full reboot: http://forums.fedoraforum.org/showthread.php?t=300166 Is systemd really like a 2nd 'kernel' -- demanding mass reboots every time a security issue is discovered? I hope not! -- ~Randy From jimpop at gmail.com Thu Oct 23 15:25:36 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 23 Oct 2014 11:25:36 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447E1E3.1010801@privacyrequired.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <5447E1E3.1010801@privacyrequired.com> Message-ID: On Wed, Oct 22, 2014 at 12:57 PM, * wrote: > Poettering's own blog for example even misleads on how systemd > and sysvinit work http://0pointer.de/blog/projects/why.html Oh look... he's related to PulseAudio and Avahi ..... If you've ever tried above average audio on Linux, then you know all about PulseAudio issues. If you've ever secured a subnet, then you know all about Avahi (aka mDNS). -Jim P. From mfidelman at meetinghouse.net Thu Oct 23 15:54:55 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 23 Oct 2014 11:54:55 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> Message-ID: <544924CF.2070908@meetinghouse.net> Jamie Lawrence wrote: > > Some may see me as a "grumpy old man" for that. I see it as a technical > conservatism for my production environments borne of having been burned by > shiny-cool-new before one too many times, and a tired dislike of being > paged out of bed over some chrome plated new hotness that crapped itself > again. > and > > But when I start wondering if my init system has a flight simulator easter > egg, well, there’s a problem, at least for me. So nicely put! :-) > It is funny to see people > use "but that approach is 40 years old!" on both sides of the argument. I think I'll stick with 4 wheels on cars for the long term. (3-wheeled motorcycles, on the other hand, are somewhat intriguing as I get older) > Most of my systems are Linux these days, and I am mostly distro-agnostic, > although my default does happen to be Debian. I do think I’m going to have > to get back up to speed on FreeBSD again. Boy would I be happy if I could get Xen Dom0, ZFS, and a DRBD-equivalent on BSD or SmartOS. Sigh... Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From Valdis.Kletnieks at vt.edu Thu Oct 23 15:56:10 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Oct 2014 11:56:10 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Your message of "Thu, 23 Oct 2014 11:25:36 -0400." References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <5447E1E3.1010801@privacyrequired.com> Message-ID: <3999.1414079770@turing-police.cc.vt.edu> On Thu, 23 Oct 2014 11:25:36 -0400, Jim Popovitch said: > On Wed, Oct 22, 2014 at 12:57 PM, * wrote: > > Poettering's own blog for example even misleads on how systemd > > and sysvinit work http://0pointer.de/blog/projects/why.html > > Oh look... he's related to PulseAudio and Avahi ..... And he has a Grand Design for Everything: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mfidelman at meetinghouse.net Thu Oct 23 15:56:59 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 23 Oct 2014 11:56:59 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <5449254B.7080600@meetinghouse.net> Randy wrote: > I've enjoyed kernel hot patches (ksplice) until now. > > So my primary concern is that updates to systemd appears to require a > full reboot: > > http://forums.fedoraforum.org/showthread.php?t=300166 > > Is systemd really like a 2nd 'kernel' -- demanding mass reboots every > time a security issue is discovered? > Well, in the sense that: - it starts out as PID1 and really, really, wants to take over lots of low level functions, it sure looks like it's trying to be a 2nd kernel Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From the.lists at mgm51.com Thu Oct 23 16:04:39 2014 From: the.lists at mgm51.com (Mike.) Date: Thu, 23 Oct 2014 12:04:39 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <201410231204390966.0073FDC1@smtp.24cl.home> On 10/23/2014 at 10:56 AM Randy wrote: |I've enjoyed kernel hot patches (ksplice) until now. | |So my primary concern is that updates to systemd appears to require a |full reboot: | |http://forums.fedoraforum.org/showthread.php?t=300166 | |Is systemd really like a 2nd 'kernel' -- demanding mass reboots every |time a security issue is discovered? | |I hope not! ============= GNU/Linux is morphing into GNU/systemd .... From jimpop at gmail.com Thu Oct 23 16:12:13 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 23 Oct 2014 12:12:13 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <201410231204390966.0073FDC1@smtp.24cl.home> References: <5445AD63.7090400@lugosys.com> <201410231204390966.0073FDC1@smtp.24cl.home> Message-ID: On Thu, Oct 23, 2014 at 12:04 PM, Mike. wrote: > > > On 10/23/2014 at 10:56 AM Randy wrote: > > |I've enjoyed kernel hot patches (ksplice) until now. > | > |So my primary concern is that updates to systemd appears to require > a > |full reboot: > | > |http://forums.fedoraforum.org/showthread.php?t=300166 > | > |Is systemd really like a 2nd 'kernel' -- demanding mass reboots > every > |time a security issue is discovered? > | > |I hope not! > ============= > > GNU/Linux is morphing into GNU/systemd .... > Let's start calling it Systemd/Linux... that will get RMS on their case real fast. :-) -Jim P. From lowen at pari.edu Thu Oct 23 17:43:03 2014 From: lowen at pari.edu (Lamar Owen) Date: Thu, 23 Oct 2014 13:43:03 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <21576.2777.349727.84982@world.std.com> References: <5445AD63.7090400@lugosys.com> Message-ID: <54493E27.4040405@pari.edu> On 10/22/2014 03:51 PM, Barry Shein wrote: > I wish I had a nickel for every time I started to implement something > in bash/sh, used it a while, and quickly realized I needed something > like perl and had to rewrite the whole thing. Barry, you've been around a long time, and these words are pearls of wisdom. This seems to be the reasoning behind replacing the spaghetti known as 'initscripts' currently written in sh with something written in a real programming language. Upstart and systemd are both responses to the inflexible spaghetti now lurking in the initscript system, of which the pile steaming in /etc/init.d is but a part. > Sure, one can insist on charging forward in sh but at some point it > becomes, as Ken Thompson so eloquently put it on another topic > entirely, like kicking a dead whale down the beach. > This seems to be the attitude of the systemd developers, although they're not as eloquent as Thompson in saying it. But I remember being just as abrasive, just on a smaller scale, myself....... Now, I've read the arguments, and I am squarely in the 'do one thing and do it well' camp. But, let's turn that on its head, shall we? Why oh why do we want every single package to implement its own initscript and possibly do it poorly? Wouldn't it be a case of 'do one thing well' if one could do away with executable shell code in each individual package that is going to run as root? Wouldn't it be more 'do one thing well' if you had a 'super' inetd setup that can start services in a better way than with individually packaged (by different packagers in most cases) shell scripts that are going to run as root? Shouldn't the initialization logic, which is 'one thing that needs doing' be in one container and not thousands? Now, I say that having been a packager for a largish RPM package several years ago. I waded the morass of the various packages' initscripts; each packager was responsible for their own script, and it was a big mess with initscripts doing potentially dangerous things (mine included; to clear it up, I maintained the PostgreSQL packages for the PostgreSQL upstream project from 1999 to 2004). Ever since 1999 there have been issues with distributed initialization logic (that runs as *root* no less) under hundreds of different packagers' control. It was and is a kludge of the kludgiest sort. Having a single executable program interpret a thousand config files written by a hundred packagers is orders of magnitude better, security-wise, than having thousands of executable (as *root*) scripts written by hundreds of different packagers, in my experienced opinion. If anything, having all initialization executable code in one monolithic package very closely monitored by several developers (and, well, for this purpose 'developers with attitudes' might not be the worst thing in the world) is more secure. It *is* a smaller attack surface than the feeping creaturism found in the typical /etc/init.d directory. And Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit and its cousin /etc/rc.local. Now, as much as I dislike this magnitude of change, it seems to me that systemd actually is more inline with the traditional Unix philosophy than the current initialization system is. But I always reserve the right to be wrong. And I am definitely not fond of the attitudes of the various systemd developers; systemd assuredly has its shortcomings. But it *is* here to stay, at least in RHEL-land, for at least the next ten years. Having said that, if you want to use Upstart, by all means use Upstart; RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered for quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6 rebuild (or actual RHEL6). And for those who bugle that systemd will be the 'end of unix as we know it' I just have one thing to trumpet: "Death of Internet Predicted. Film at Eleven." From zacharyw09264 at gmail.com Thu Oct 23 18:02:55 2014 From: zacharyw09264 at gmail.com (Zachary) Date: Thu, 23 Oct 2014 14:02:55 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <54493E27.4040405@pari.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> <5EA9A87201F2AB42BFD9B954797F19BE0338B21B@PRA-IAD-MAIL.pra.ray.com> <21576.2777.349727.84982@world.std.com> <54493E27.4040405@pari.edu> Message-ID: This is a good point, but it is perfectly possible to have a sysvinit system not written in shell scripts. I had rewritten most of the init system in python at one point for example. And its only been made easier to do over time now that #! Interpertation was moved kernelside. A system like this could solve all the problems of both sides since it is now a proper programming language so we can do more config style initscripts without the blob that is systemd. And for parallel init, you can do it in bash, iirc Gentoo does parallel init in bash. On Oct 23, 2014 1:45 PM, "Lamar Owen" wrote: > On 10/22/2014 03:51 PM, Barry Shein wrote: > >> I wish I had a nickel for every time I started to implement something >> in bash/sh, used it a while, and quickly realized I needed something >> like perl and had to rewrite the whole thing. >> > > Barry, you've been around a long time, and these words are pearls of > wisdom. > > This seems to be the reasoning behind replacing the spaghetti known as > 'initscripts' currently written in sh with something written in a real > programming language. Upstart and systemd are both responses to the > inflexible spaghetti now lurking in the initscript system, of which the > pile steaming in /etc/init.d is but a part. > > Sure, one can insist on charging forward in sh but at some point it >> becomes, as Ken Thompson so eloquently put it on another topic >> entirely, like kicking a dead whale down the beach. >> >> This seems to be the attitude of the systemd developers, although > they're not as eloquent as Thompson in saying it. But I remember being > just as abrasive, just on a smaller scale, myself....... > > Now, I've read the arguments, and I am squarely in the 'do one thing and > do it well' camp. But, let's turn that on its head, shall we? Why oh why > do we want every single package to implement its own initscript and > possibly do it poorly? Wouldn't it be a case of 'do one thing well' if one > could do away with executable shell code in each individual package that is > going to run as root? Wouldn't it be more 'do one thing well' if you had a > 'super' inetd setup that can start services in a better way than with > individually packaged (by different packagers in most cases) shell scripts > that are going to run as root? Shouldn't the initialization logic, which > is 'one thing that needs doing' be in one container and not thousands? > > Now, I say that having been a packager for a largish RPM package several > years ago. I waded the morass of the various packages' initscripts; each > packager was responsible for their own script, and it was a big mess with > initscripts doing potentially dangerous things (mine included; to clear it > up, I maintained the PostgreSQL packages for the PostgreSQL upstream > project from 1999 to 2004). Ever since 1999 there have been issues with > distributed initialization logic (that runs as *root* no less) under > hundreds of different packagers' control. It was and is a kludge of the > kludgiest sort. > > Having a single executable program interpret a thousand config files > written by a hundred packagers is orders of magnitude better, > security-wise, than having thousands of executable (as *root*) scripts > written by hundreds of different packagers, in my experienced opinion. If > anything, having all initialization executable code in one monolithic > package very closely monitored by several developers (and, well, for this > purpose 'developers with attitudes' might not be the worst thing in the > world) is more secure. It *is* a smaller attack surface than the feeping > creaturism found in the typical /etc/init.d directory. And Barry's pearl > of wisdom above most definitely applies to /etc/rc.sysinit and its cousin > /etc/rc.local. > > Now, as much as I dislike this magnitude of change, it seems to me that > systemd actually is more inline with the traditional Unix philosophy than > the current initialization system is. But I always reserve the right to be > wrong. And I am definitely not fond of the attitudes of the various > systemd developers; systemd assuredly has its shortcomings. But it *is* > here to stay, at least in RHEL-land, for at least the next ten years. > > Having said that, if you want to use Upstart, by all means use Upstart; > RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered for > quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6 > rebuild (or actual RHEL6). > > And for those who bugle that systemd will be the 'end of unix as we know > it' I just have one thing to trumpet: > > "Death of Internet Predicted. Film at Eleven." > > From houdini+nanog at clanspum.net Thu Oct 23 18:10:45 2014 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Thu, 23 Oct 2014 13:10:45 -0500 Subject: Paging someone at Savvis [AS 3561] Message-ID: <20141023181045.GF11519@clanspum.net> I'd like to talk to someone with clue about open NTPd on a router of yours. Normal support channels are totally failing me. -- Bill Weiss From Valdis.Kletnieks at vt.edu Thu Oct 23 18:22:08 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Oct 2014 14:22:08 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: Your message of "Thu, 23 Oct 2014 13:43:03 -0400." <54493E27.4040405@pari.edu> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <54469515.5020104@lugosys.com> <90FAC821-7AD1-4369-B99B-00F2D109953F@delong.com> <5EA9A87201F2AB42BFD9B954797F19BE0338B21B@PRA-IAD-MAIL.pra.ray.com> <21576.2777.349727.84982@world.std.com> <54493E27.4040405@pari.edu> Message-ID: <13013.1414088528@turing-police.cc.vt.edu> On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said: > Now, I've read the arguments, and I am squarely in the 'do one thing and > do it well' camp. But, let's turn that on its head, shall we? Why oh > why do we want every single package to implement its own initscript and > possibly do it poorly? Umm.. because maybe, just maybe, the package maintainers know more about the ugly details of what it takes to start a given package than the init system authors know? If they botch the boilerplate section of an initscript, maybe they shouldn't be releasing packages. On the other hand, the *non*-boilerplate section of the initscript is something that *only* the package maintainers are qualified to write. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From danny at tcb.net Thu Oct 23 18:26:50 2014 From: danny at tcb.net (Danny McPherson) Date: Thu, 23 Oct 2014 12:26:50 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> Message-ID: <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived "policies" there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental "putty" and small practical steps to fill the gaps at this point. I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. Alas, -danny From christopher.morrow at gmail.com Thu Oct 23 18:33:41 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 23 Oct 2014 14:33:41 -0400 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: On Oct 23, 2014 2:27 PM, "Danny McPherson" wrote: > > > > I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived "policies" there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. > > As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental "putty" and small practical steps to fill the gaps at this point. > > > > I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. > Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Did you see wes's slides / talk at the last nanog? > Alas, > > -danny > > From bzs at world.std.com Thu Oct 23 17:12:22 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 23 Oct 2014 13:12:22 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> Message-ID: <21577.14070.945683.385862@world.std.com> On October 22, 2014 at 15:31 jfbeam at gmail.com (Ricky Beam) wrote: > On Wed, 22 Oct 2014 14:31:02 -0400, Barry Shein wrote: > > Perhaps you don't remember the days when an fsck was > > basically mandatory and could take 15-20 minutes on a large disk. > > Journaling has all but done away with fsck. You'd have to go *way* back to > have systems that ran a full fsck on every boot -- and in my experience, > you absolutely wanted that fsck. That was my point, it was a very brief and concise 30 year history. That's why I mentioned the introduction of the clean bit which was when we began recording (there may have been earlier experiments) the clean unmounting of a file system in the superblock so no need to fsck. > > And you whisk all that away with "it's not really clear to me that > > 'reboots in seconds' is a think to be optimized"???? (I hope it's clear I meant "thing to be opt...") > > Your efforts are better spent avoiding an outage in the first place. If > outages are common enough to be something that needs to be "sped up", then > you've already failed. One important tool is failover. But once a system fails over you'd like to see the failed component back in service as quickly as possible unless you have an infinite number of redundant systems. Your advice doesn't ring true to me. -- -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 bzs at world.std.com Thu Oct 23 17:27:02 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 23 Oct 2014 13:27:02 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.62558.449089.867918@world.std.com> Message-ID: <21577.14950.544318.154925@world.std.com> On October 23, 2014 at 04:42 randy at psg.com (Randy Bush) wrote: > Barry Schein: Interesting you went to the trouble to add a 'c' to my name! You need better quoting tools. > > I'm reminded of the remark often attributed to DEC CEO Ken Olson, > > roughly: > > > > With VMS (their big complex OS) it might take hours searching > > through manuals to find a feature you need while with Unix you can > > determine in seconds that it is not available. > > and how did that work out for vms? and digital? A few people made billions, a few more made many millions, hundreds of thousands (or thereabouts) had pretty good jobs for upwards of 20 years, and then the second largest computer company in the world vaporized almost mysteriously. The VAX hardware was important. It was for the time relatively inexpensive and very capable, the 32-bit address space (ok, technically four 30 bit addr spaces) and VM hardware at those prices were revolutionary. You had many of the capabilities of a multi-million dollar mainframe for about 1/10th the cost. Ran Unix great! VMS not so much. Mostly re-warmed over RSX (an earlier DEC OS) with a few new ideas to take advantage of the platform, and some cobbling from their TOPS-10 and TOPS-20 OS's (e.g. galaxy.) IMHO DEC desparately wanted to go head on with IBM's 370 line but just didn't seem to "get" why companies bought IBM mainframes, or found those parts too expensive to compete on. But they did ok financially anyhow so who's to criticize? VMS even had PIP! And sometimes you needed it. -- -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 bzs at world.std.com Thu Oct 23 18:33:01 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 23 Oct 2014 14:33:01 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <21574.45051.625317.910556@world.std.com> <20141021201019.GE36267@dyn.com> <21575.63462.45782.746718@world.std.com> <5448262C.50406@jack.fr.eu.org> Message-ID: <21577.18909.75916.670285@world.std.com> Going way off topic but what's still a disaster in log files is the lack of standardization of output. As another extreme OS/370 catalogued virtually (hah) every error msg, if you thought you had a new one you added it to the catalogue as you added it to an error msg in your program and it was likely someone informed you something sufficient already existed, or you just specialized an existing code -- e.g., IED101203EA77... might mean daemon, file system problem, insufficient privilege, recoverable/unrecoverable, etc and then you could add a few more digits (...) to make it unique if you liked or use a known value and some free format text as per usual if desired. System/Kernel/Library wide. I realize there have been a few very weak attempts at this with *ix like errno, strerror (which for some bizarre reason never prints the errno or symbolic error only some text albeit from a known table), sysexits.h, %m in syslog which is just strerror(), etc. But syslog et al needs to go way beyond the daemon, time, and priority and free format text so log analyzers (including grep) have half a chance. Just my 2c. -- -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 lowen at pari.edu Thu Oct 23 19:50:21 2014 From: lowen at pari.edu (Lamar Owen) Date: Thu, 23 Oct 2014 15:50:21 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <13013.1414088528@turing-police.cc.vt.edu> References: <5445AD63.7090400@lugosys.com> Message-ID: <54495BFD.4010205@pari.edu> On 10/23/2014 02:22 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said: > >> Now, I've read the arguments, and I am squarely in the 'do one thing and >> do it well' camp. But, let's turn that on its head, shall we? Why oh >> why do we want every single package to implement its own initscript and >> possibly do it poorly? > Umm.. because maybe, just maybe, the package maintainers know more about > the ugly details of what it takes to start a given package than the init > system authors know? Speaking from my own experience, the actually relevant and package-specific guts of the typical initscript could be easily replaced by a simple text configuration that simply gives: 1.) What to start 2.) When to start it (traditional initscripts work on a linear timeline of priority slots; systemd units have more flexibility) 3.) How to start it (command line options) This should not need to be an executable script. This is what systemd brings to the table (Upstart brought some of this, too). It allows the packager to declare those details that the packager knows about the package and eliminates the boilerplate (that is different between versions of the same distribution; I for one maintained initscripts across multiple versions of multiple distributions, all of which had different boilerplate and different syntax). I should not have needed to learn all the different boilerplate, as that was a distraction from the real meat of packaging (it could be argued that the presence of syntactically arcane boilerplate is a problem in and of itself: as a for instance, the nice 'daemon' function most RPM-based distributions supply in /etc/init.d/functions works for some initscripts and not for others; PostgreSQL is one for which it doesn't work and it's not obvious at first glance why it doesn't); I should simply have been able to tell the init system in a declarative syntax that I needed to start the program '/usr/bin/postmaster' with the command line options for database directory and listening port (among some other items). And that includes 99% of what the various initscripts do (yeah, the PostgreSQL script of which I was one author did one thing that in hindsight should simply not have been in the initscript at all). Many of the 1% exceptions perhaps don't belong in code that is run as root every single time that particular daemon needs to start or stop. The perhaps 0.5% remaining that absolutely must be run before starting or stopping, well, yes, there should be an option in that declarative syntax to say, for instance, 'before starting /usr/bin/postmaster, check the version of the database and fail if it's older with a message to the log telling the admin they need to DUMP/RESTORE the database prior to trying to start again' ...... (the systemd syntax does allow this). I have personally compared the current PostgreSQL systemd unit (/usr/lib/systemd/system/postgresql.service on my CentOS 7 system) to the old initscript. I wish it had been that simple years ago; the .service file is much cleaner, clearer, and easier to understand; no funky shell quote escapes needed. And it doesn't execute as root, nor does it source arcane boilerplate functions, the source of some of which will make your eyes bleed. And to do a customized version you just drop your edited copy in /etc/systemd/system/ and you're done, since it won't get overwritten when you update packages. When configuring Cisco IOS, we use a declarative syntax; the systemd .service file's syntax is as readable as the typical startup-confg is. Imagine if we used the typical bash initscript syntax to bring up interfaces and services on our routers. From list at satchell.net Thu Oct 23 19:54:47 2014 From: list at satchell.net (Stephen Satchell) Date: Thu, 23 Oct 2014 12:54:47 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <54493E27.4040405@pari.edu> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> Message-ID: <54495D07.3040405@satchell.net> On 10/23/2014 10:43 AM, Lamar Owen wrote: > Wouldn't it be more 'do one thing well' if you had a 'super' inetd > setup that can start services in a better way than with individually > packaged (by different packagers in most cases) shell scripts that are > going to run as root? inetd versus xinetd -- I thought that was an excellent change. It was closely targeted, well documented, and did indeed do one thing well: accept connections and pass them off to a handler. I'm not so sure about systemd yet. I've not tried to create a daemon of my own to run under the setup. I have tried to use upstart, and found the execution of upstart (CentOS 6) didn't match the documentation. Further, there was no "here's how you go from sysvinit to upstart" that made sense. I did see that systemd *does* have a paper for people needing to move from the old sysvinit to systemd, which is a plus on the surface. I'll be trying that in the future. From mpalmer at hezmatt.org Thu Oct 23 20:02:41 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 24 Oct 2014 07:02:41 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <201410231204390966.0073FDC1@smtp.24cl.home> Message-ID: <20141023200241.GN16429@hezmatt.org> On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote: > On Thu, Oct 23, 2014 at 12:04 PM, Mike. wrote: > > GNU/Linux is morphing into GNU/systemd .... > > Let's start calling it Systemd/Linux... that will get RMS on their > case real fast. :-) I don't think they've done anything to deserve *that*... - Matt -- I don't do veggies if I can help it. -- stevo If you could see your colon, you'd be horrified. -- Iain Broadfoot If he could see his colon, he'd be management. -- David Scheidt From mpalmer at hezmatt.org Thu Oct 23 20:07:28 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 24 Oct 2014 07:07:28 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <20141023200728.GO16429@hezmatt.org> On Thu, Oct 23, 2014 at 10:56:40AM -0400, Randy wrote: > I've enjoyed kernel hot patches (ksplice) until now. > > So my primary concern is that updates to systemd appears to require > a full reboot: > > http://forums.fedoraforum.org/showthread.php?t=300166 > > Is systemd really like a 2nd 'kernel' -- demanding mass reboots > every time a security issue is discovered? But it's OK, because it reboots so *fast*! - Matt -- [O]ne of the requirements for writing code in Python seems to be that one spends as least as much time promoting the language as coding in it. -- Matt Roberds, in the Monastery From mfidelman at meetinghouse.net Thu Oct 23 20:17:14 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 23 Oct 2014 16:17:14 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141023200241.GN16429@hezmatt.org> References: <5445AD63.7090400@lugosys.com> <201410231204390966.0073FDC1@smtp.24cl.home> <20141023200241.GN16429@hezmatt.org> Message-ID: <5449624A.6030109@meetinghouse.net> Matt Palmer wrote: > On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote: >> On Thu, Oct 23, 2014 at 12:04 PM, Mike. wrote: >>> GNU/Linux is morphing into GNU/systemd .... >> Let's start calling it Systemd/Linux... that will get RMS on their >> case real fast. :-) > I don't think they've done anything to deserve *that*... > > PulseAudio, systemd - yeah... maybe they have :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From danny at tcb.net Thu Oct 23 20:18:43 2014 From: danny at tcb.net (Danny McPherson) Date: Thu, 23 Oct 2014 14:18:43 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: On 2014-10-23 12:33, Christopher Morrow wrote: > Sounds like you want to see the rirs make sure they get rpki work > dine and widely available with the least encumbrances on the network > operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. > Did you see wes's slides / talk at the last nanog? I did (after). Aside, I understand why the ARIN board did what they did with the RPA and I don't blame them -- it seemed well considered to me, but that's just me. Reminded of Taleb's "Fat Tony" quote [paraphrased]: If the pilot ain't on the plane, you probably don't want to get on it, -danny From jared at puck.nether.net Thu Oct 23 20:54:17 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 23 Oct 2014 16:54:17 -0400 Subject: inexpensive KVMoIP Message-ID: Having recently encountered a problem with a machine, I’m looking for an inexpensive KVMoIP device to place within a facility to take VGA/USB Keyboard for a single host scale. Ideally something that can be properly placed on the internet, but that’s not a showstopper. If you’re willing to loan me one for a week or two as well, let me know too so I can ship it to the site and recover my machine. (Time to start moving to next-gen for personal servers.. *sigh*). - Jared From mpalmer at hezmatt.org Thu Oct 23 20:56:12 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 24 Oct 2014 07:56:12 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5449624A.6030109@meetinghouse.net> References: <5445AD63.7090400@lugosys.com> <201410231204390966.0073FDC1@smtp.24cl.home> <20141023200241.GN16429@hezmatt.org> <5449624A.6030109@meetinghouse.net> Message-ID: <20141023205612.GX16429@hezmatt.org> On Thu, Oct 23, 2014 at 04:17:14PM -0400, Miles Fidelman wrote: > Matt Palmer wrote: > >On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote: > >>On Thu, Oct 23, 2014 at 12:04 PM, Mike. wrote: > >>>GNU/Linux is morphing into GNU/systemd .... > >>Let's start calling it Systemd/Linux... that will get RMS on their > >>case real fast. :-) > >I don't think they've done anything to deserve *that*... > > PulseAudio, systemd - yeah... maybe they have :-) Of all the PoetteringStuff out there, PA's the one that's caused me the least problems. I know that I'm in some vanishingly small minority there, because it seems to cause problems for everyone around me. One of my colleagues needs to "jiggle the wires" every time he wants to use gHangouts because PA gets itself in a tizzy. Now *Avahi*, on the other hand... FML. - Matt From job at instituut.net Thu Oct 23 20:59:53 2014 From: job at instituut.net (Job Snijders) Date: Thu, 23 Oct 2014 22:59:53 +0200 Subject: inexpensive KVMoIP In-Reply-To: References: Message-ID: <20141023205953.GJ759@Vurt.local> On Thu, Oct 23, 2014 at 04:54:17PM -0400, Jared Mauch wrote: > Having recently encountered a problem with a machine, I’m looking for > an inexpensive KVMoIP device to place within a facility to take > VGA/USB Keyboard for a single host scale. Ideally something that can > be properly placed on the internet, but that’s not a showstopper. > > If you’re willing to loan me one for a week or two as well, let me > know too so I can ship it to the site and recover my machine. > > (Time to start moving to next-gen for personal servers.. *sigh*). I really enjoy carrying this in my back pack: http://www.lantronix.com/it-management/kvm-over-ip/spiderduo.html Even supports ipv6. I often ssh into it based on link-local address to figure out it's DHCP IPv4 address Kind regards, Job From alh-ietf at tndh.net Thu Oct 23 21:01:38 2014 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 23 Oct 2014 14:01:38 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <047401cfef04$89d7e990$9d87bcb0$@tndh.net> Randy wrote: > I've enjoyed kernel hot patches (ksplice) until now. > > So my primary concern is that updates to systemd appears to require a full > reboot: > > http://forums.fedoraforum.org/showthread.php?t=300166 > > Is systemd really like a 2nd 'kernel' -- demanding mass reboots every time a > security issue is discovered? > > I hope not! > > -- > ~Randy Given that their focus is on reducing boot-time, why wouldn't they want to highlight that point by making you do it often?? It is clear that the systemd developers are on a solid track to catch up with Windows-9x/ME. At the timeframe of Win9x/ME development, Gates was hammering "boot-time : boot-time : boot-time" on a regular basis. My feedback to him and his direct reports was that getting rid of reasons to reboot was much more important than making an all too common activity "less unpleasant". Clearly a monolithic super ker-daemon will be at least as easy to use and maintain as a Win9x machine ... ;) Tony From sandy at tislabs.com Thu Oct 23 21:02:41 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 23 Oct 2014 17:02:41 -0400 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: <8B78FB63-844E-4135-837D-B08DD647BD1D@tislabs.com> > IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects. That would help solve the trust problem in the current IRR world, which is that most IRRs can't tell if the object being registered is authorized. RIPE and, I think, APNIC being the exception, for their region resources. Lots of proxy registered objects aren't a good sign. --Sandy On Oct 23, 2014, at 2:26 PM, Danny McPherson wrote: > > > I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived "policies" there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. > > As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental "putty" and small practical steps to fill the gaps at this point. > > > > I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. > > Alas, > > -danny > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ssaner at hubris.net Thu Oct 23 21:04:48 2014 From: ssaner at hubris.net (Steven Saner) Date: Thu, 23 Oct 2014 16:04:48 -0500 Subject: inexpensive KVMoIP In-Reply-To: References: Message-ID: <54496D70.80602@hubris.net> On 10/23/2014 03:54 PM, Jared Mauch wrote: > Having recently encountered a problem with a machine, I’m looking for an inexpensive KVMoIP device to place within a facility to take VGA/USB Keyboard for a single host scale. Ideally something that can be properly placed on the internet, but that’s not a showstopper. > > If you’re willing to loan me one for a week or two as well, let me know too so I can ship it to the site and recover my machine. > > (Time to start moving to next-gen for personal servers.. *sigh*). > > - Jared > These work pretty fair: http://www.adder.com/products/adderlink-digital-ipeps The older versions had VGA input. Looks like the newer ones are DVI. Might be able to find an older used one someplace. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From danny at tcb.net Thu Oct 23 21:13:15 2014 From: danny at tcb.net (Danny McPherson) Date: Thu, 23 Oct 2014 15:13:15 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <8B78FB63-844E-4135-837D-B08DD647BD1D@tislabs.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <8B78FB63-844E-4135-837D-B08DD647BD1D@tislabs.com> Message-ID: On 2014-10-23 15:02, Sandra Murphy wrote: >> IRR usage, training, tools, and better hygiene, perhaps expressly >> validated from resource certification from either RPKI > > You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which > suggests using RPKI to protect RPSL objects. Yep, I'm aware of that and think that's a really useful thing if RPKI is the resource certification infrastructure we must use. > That would help solve the trust problem in the current IRR world, > which is that most IRRs can't tell if the object being registered is > authorized. RIPE and, I think, APNIC being the exception, for their > region resources. Lots of proxy registered objects aren't a good > sign. Agreed! That said, if people are still having issues with IRRs and lack of training, toolsets, and usability around them today and after deploying RPKI they still need IRRs (and whois, and in-addr.arpa, and..) for a whole bunch of stuff just to keep the packets flowing then the height limit to do basic and useful things just became that much higher, and requires a lot more care and feeding then before RPKI (even absent all the architectural aspects of RPKI that are "interesting"). -danny From warren at kumari.net Thu Oct 23 21:58:36 2014 From: warren at kumari.net (Warren Kumari) Date: Thu, 23 Oct 2014 17:58:36 -0400 Subject: An update from the ICANN ISPCP meeting... Message-ID: Those of y'all who were at NANOG62 may remember a presentation from the ICANN Internet Service Provider and Connectivity Providers Constituency (ISPCP). I feel somewhat bad because I misunderstood what they were sayingin, and kinda lost my cool during the preso. Anyway, the ISPCP met at ICANN 51 last week. Unfortunately I was not able to attend, but the meeting audio stream is posted at: http://la51.icann.org/en/schedule/tue-ispcp If you'd rather read than listen, the transcript is posted here: http://la51.icann.org/en/schedule/tue-ispcp/transcript-ispcp-14oct14-en.pdf I snipped a bit that mentions NANOG: The next outreach experience that we had was at NANOG. NANOG, as you may know, is the North American Network Operators Group, an area where we really wanted to make an impact because it is the network operators groups that can really bring the insight that we need to act on being a unique and special voice within the ICANN community on issues that matter to ISPs around some of the things that are on our agenda today, such as universal access, such as name collisions. And we wanted to get more technical voices in the mix and more resources in the door so that we could make a better impact there. A lot of what we received when we stood up to give our presentation were messages from people who had attempted to engage in ICANN in the past or attempted to engage in the ISPCP in the past and had had very difficult time doing. They said when you come into this arena you spend so much time talking about process, so much time talking about Whois and what board seats, about what needs to happen around transparency. I'm a technical guy, I want to focus on technical issues and I don't have a unique venue for being able to do that. So we spent some time as a group trying to figure out how we can address that because we do need those voices. Our goal has been to take the feedback that we receive from NANOG and create an action plan to make sure that we can pull in voices like that and go back to the NOG community, go back to the technical operators community, bring them on board and say we've got a different path for you. Anyway, go listen / read the full transcript if you are so inclined... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From brunner at nic-naa.net Thu Oct 23 22:15:31 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 23 Oct 2014 15:15:31 -0700 Subject: An update from the ICANN ISPCP meeting... In-Reply-To: References: Message-ID: <54497E03.5020207@nic-naa.net> some history. at the montevideo icann meeting (september, 2001), there were so few attendees to either the ispc (now ispcp) and the bc (still bc), that these two meetings merged. at the paris icann meeting (june, 2008) staff presented an analysis of the voting patters of the gnso constituencies -- to my non-surprise, both the bc and the ispc votes (now ispcp) correlated very highly with the intellectual property constituency, and unlike that constituency, originated very little in the way of policy issues for which an eventual vote was recorded. in other words, the bc and ispc were, and for the most part, imho, remain captive properties of the intellectual property constituency. this could change, but the isps that fund suits need to change the suits they send, the trademark lawyer of eyeball network operator X is not the vp of ops of network operator X. meanwhile, whois, the udrp, and other bits o' other-people's-business-model take up all the available time. eric On 10/23/14 2:58 PM, Warren Kumari wrote: > Those of y'all who were at NANOG62 may remember a presentation from the ICANN > Internet Service Provider and Connectivity Providers Constituency (ISPCP). > > I feel somewhat bad because I misunderstood what they were sayingin, > and kinda lost my cool during the preso. Anyway, the ISPCP met at > ICANN 51 last week. Unfortunately I was not able to attend, but the > meeting audio stream is posted at: > http://la51.icann.org/en/schedule/tue-ispcp > > If you'd rather read than listen, the transcript is posted here: > http://la51.icann.org/en/schedule/tue-ispcp/transcript-ispcp-14oct14-en.pdf > > I snipped a bit that mentions NANOG: > > The next outreach experience that we had was at NANOG. NANOG, as you > may know, is the North American Network Operators Group, an area where > we really wanted to make an impact because it is the network operators > groups that can really bring the insight that we need to act on being a unique > and special voice within the ICANN community on issues that matter to ISPs > around some of the things that are on our agenda today, such as universal > access, such as name collisions. And we wanted to get more technical voices > in the mix and more resources in the door so that we could make a better > impact there. > A lot of what we received when we stood up to give our presentation were > messages from people who had attempted to engage in ICANN in the past or > attempted to engage in the ISPCP in the past and had had very difficult time > doing. They said when you come into this arena you spend so much time > talking about process, so much time talking about Whois and what board > seats, about what needs to happen around transparency. I'm a technical guy, > I want to focus on technical issues and I don't have a unique venue for being > able to do that. > So we spent some time as a group trying to figure out how we can address > that because we do need those voices. Our goal has been to take the > feedback that we receive from NANOG and create an action plan to make > sure that we can pull in voices like that and go back to the NOG community, > go back to the technical operators community, bring them on board and say > we've got a different path for you. > > > > Anyway, go listen / read the full transcript if you are so inclined... > > W > > From randy at psg.com Thu Oct 23 23:00:58 2014 From: randy at psg.com (Randy Bush) Date: Fri, 24 Oct 2014 08:00:58 +0900 Subject: inexpensive KVMoIP In-Reply-To: References: Message-ID: i can hand you a spider at ripe or ietf. or ship if you are desperate. randy From simon at darkmere.gen.nz Thu Oct 23 23:01:16 2014 From: simon at darkmere.gen.nz (Simon Lyall) Date: Fri, 24 Oct 2014 12:01:16 +1300 (NZDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5448A566.3060700@satchell.net> References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> <5448A566.3060700@satchell.net> Message-ID: On Wed, 22 Oct 2014, Stephen Satchell wrote: > On 10/22/2014 08:20 PM, Simon Lyall wrote: >> On Wed, 22 Oct 2014, Miles Fidelman wrote: >>> And maybe, you should check out some of the upstream bug reports re. >>> systemd interactions with NTP. >> >> If you think the current situation is all good then maybe you should >> look at other bugs for ntp. eg this one I that affected me with Ubuntu >> Disktop. They only run time syncing when the network is bounced so if >> you have a stable network then your machine will never sync: >> >> https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933 [..] > I'm a long-time user of NTP, and what you are asking for is a no-good > way of doing things. What you are supposed to do is use the ntpdate(8) > utility *ONCE* on boot to initially set the system clock, then you have > ntpd(8) running to do two things for you: sync up to one or more time > sources, and discipline the local clock. [..] > That's the SERVER way of running a time synchronization. So it would > appear that you have a quarrel with GUI support, not with NTP itself. What my point was is that the "simple default for end users" [1] is already significantly broken in Ubuntu (that is just one bug that bit me, there are plenty of others). The systemd system seems to offer and improvement on the existing "simple default" setup while still enabling experts to run a full ntpd install if they wish. [1] - I know how to setup and run ntpd, I didn't expect to need to do it on my workstation however. -- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar From larrysheldon at cox.net Thu Oct 23 23:35:35 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 23 Oct 2014 18:35:35 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <6Z0K1p00M1cZc5601Z0MsQ> References: <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <41894.1414030725@turing-police.cc.vt.edu> <6Z0K1p00M1cZc5601Z0MsQ> Message-ID: <544990C7.8070803@cox.net> On 10/23/2014 02:15, Matt Palmer wrote: > This is the core problem with systemd, in my mind -- and what has gotten > Linus, amongst other people, so thoroughly cheesed off with the systemd > devs. They don't play well with other children. They don't appear > particularly interested in reusing any existing code, because it's a lot > more fun to write new code. I'm a strong proponent of Joel Spolsky's views > on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the > same problems will come to haunt systemd on its way from being the new kid > on the block to being legacy code[1]. > > - Matt > > [1] A computer industry term which means, "it works". ...and has for more than a month. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From dougb at dougbarton.us Thu Oct 23 23:51:21 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 23 Oct 2014 16:51:21 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: References: <5445AD63.7090400@lugosys.com> <5447D757.8010307@meetinghouse.net> <20141022214335.GA8447@gsp.org> <54484D79.1070607@lugosys.com> <54485B57.8060406@meetinghouse.net> <54486322.7020005@meetinghouse.net> <5448A566.3060700@satchell.net> Message-ID: <54499479.1030607@dougbarton.us> On 10/23/14 4:01 PM, Simon Lyall wrote: > On Wed, 22 Oct 2014, Stephen Satchell wrote: >> On 10/22/2014 08:20 PM, Simon Lyall wrote: >>> On Wed, 22 Oct 2014, Miles Fidelman wrote: >>>> And maybe, you should check out some of the upstream bug reports re. >>>> systemd interactions with NTP. >>> >>> If you think the current situation is all good then maybe you should >>> look at other bugs for ntp. eg this one I that affected me with Ubuntu >>> Disktop. They only run time syncing when the network is bounced so if >>> you have a stable network then your machine will never sync: >>> >>> https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933 > [..] >> I'm a long-time user of NTP, and what you are asking for is a no-good >> way of doing things. What you are supposed to do is use the ntpdate(8) >> utility *ONCE* on boot to initially set the system clock, then you have >> ntpd(8) running to do two things for you: sync up to one or more time >> sources, and discipline the local clock. > [..] >> That's the SERVER way of running a time synchronization. So it would >> appear that you have a quarrel with GUI support, not with NTP itself. > > What my point was is that the "simple default for end users" [1] is > already significantly broken in Ubuntu (that is just one bug that bit > me, there are plenty of others). > > The systemd system seems to offer and improvement on the existing > "simple default" setup while still enabling experts to run a full ntpd > install if they wish. > > [1] - I know how to setup and run ntpd, I didn't expect to need to do it > on my workstation however. If you are actually arguing that because Ubuntu made a mistake on how the "Internet time synchronization" option is configured, therefore we need systemd, you need to rethink your position. :) FWIW, the problem you're describing with that option is real, and was revisited in later versions. As of 14.04 it was still broken, but for a different reason having to do with permissions on the ntpd install. However, fixing that problem doesn't require systemd, it requires fixing *that* problem. I am not against systemd per se, I honestly don't know enough about it to form an intelligent opinion. The line of reasoning (I believe to be) espoused here is quite concerning, "If there is a problem, we need to bring the solution into systemd." To the extent that's accurate, it's overwhelmingly likely to be wrong. I could say a lot more about Unix system design philosophies from my time in the FreeBSD project, but this thread started off-topic, and has only gotten worse. :) Doug From drc at virtualized.org Fri Oct 24 02:27:03 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 23 Oct 2014 19:27:03 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <54497E03.5020207@nic-naa.net> References: <54497E03.5020207@nic-naa.net> Message-ID: Hi, While I'm sure most of the folks on NANOG are fully aware of the myriad of acronyms and Byzantine structures in the ICANN universe (:)), I thought some translation for those not inoculated with ICANNese may be helpful: On Oct 23, 2014, at 3:15 PM, Eric Brunner-Williams wrote: > some history. > > at the montevideo icann meeting (september, 2001), there were so few attendees to either the ispc (now ispcp) and the bc (still bc), Translated: At a meeting in Uruguay in 2001 (one of the 3 times per year meetings ICANN holds all over the world in accordance with its Bylaws requirement to be a global organization and/or the desire of those who came up with the Bylaws to have many fine lunches and dinners in exotic places), very few people attended the working group meetings purportedly chartered for the interests of ISPs (the "ISP Constituency" or ISPC) and the meetings purportedly chartered for typically e-commerce related business interests (the "Business Constituency" or BC). For those interested and/or who have morbid curiosity, both of these constituencies have their own web pages: ISPCP: http://ispcp.info BC: http://www.bizconst.org The parentheticals note the ISP Constituency was renamed to the "ISP and Connectivity Provider" Constituency (ISPCP) and the Business Constituency is still named the BC. I do not know for sure what the rationale was behind the renaming (I'm guessing it was to increase the number of folks the Constituency would be relevant to). > that these two meetings merged. You could see this either as a desire to have something like a "joint working group meeting" in IETF parlance or a desire to have a few people in a single room instead of a couple of people in two rooms to try to avoid awkwardness (in my experience, the ISPCP meetings are not particularly well attended -- this may have changed: I haven't been in a while. I can't comment on the BC meetings since I've never been.) > at the paris icann meeting (june, 2008) staff presented an analysis of the voting patters of the gnso constituencies GNSO: Generic Names Supporting Organization, the folks who care sufficiently deeply about generic top-level domains to go to places like Montevideo and Paris for a week to scream past... err... reach consensus with other individuals who care deeply about generic top-level domains. The GNSO is made up of a bunch of Constituencies, of which the ISPCP and BC are two. There are more. There are two other Supporting Organizations, the ccNSO for country code TLDs and the ASO, the Addressing Supporting Organization, made up of folks elected by the RIRs. > -- to my non-surprise, both the bc and the ispc votes (now ispcp) correlated very highly with the intellectual property constituency, Yet another GNSO Constituency: the Intellectual Property Constituency (IPC), focused on trying to protect the interests of Intellectual Property Rights owners in the areas ICANN touches. IPC: http://www.ipconstituency.org I think it safe to say that much (but not all) of the warfare that goes on at ICANN meetings is between the folks interested in protecting IPR (in this context, trademarks) and folks interested in selling oodles of domain names. > and unlike that constituency, originated very little in the way of policy issues for which an eventual vote was recorded. I am, in fact, unaware of any policy issues originated out of the ISPCP or BC (but again, I'm not too familiar with these groups). From a purely technical policy perspective, this may be considered to be ... unfortunate. That is, many of the folk on this mailing list undoubtedly have a view on what ICANN does yet those views are not relayed in a way the ICANN community can hear. > in other words, the bc and ispc were, and for the most part, imho, remain captive properties of the intellectual property constituency. Here, Eric is suggesting the intellectual property folks are driving policy issues on behalf of the folks interested in security/stability of e-commerce and as well as ISPs and connectivity providers. I have no reason to doubt Eric's opinion as I've not been involved enough in that part of ICANN and he has. > this could change, but the isps that fund suits need to change the suits they send, the trademark lawyer of eyeball network operator X is not the vp of ops of network operator X. Indeed, and I must commend Warren and Eric for caring enough to actually engage in this stuff. While many people in the NANOG/IETF/DNS Operations communities complain about the latest abomination ICANN is inflicting upon the world, there aren't a whole lot of folks from those communities who take the (non-trivial) amount of time to try to understand and address the situation. While I fully understand the rationales for not participating, the lack of strong representation from the technical community does not help in preventing abominations. > meanwhile, whois, the udrp, and other bits o' other-people's-business-model take up all the available time. UDRP: The "Uniform Domain Name Dispute Resolution Policy" (I do not know why it isn't referenced as the UDNDRP or "udden-drip"). This is the mechanism by which people who believe a domain name is being used abusively can attempt to have that abuse stopped. Folks who have been through UDRP disputes can comment on their view of its effectiveness. Examples of "other bits o' other-peope's-business-model" might include stuff like how to improve accuracy in the registration databases so anti-abuse folks can have more hope finding spammers or how culturally/liguistically-identical-but-represented-by-different-Unicode-glyphs strings can be deployed as new top-level domains (by analogy, imagine if the DNS was not case insensitive for LDH labels and the 'fun' that would occur if different organizations were allowed to sell names out of the two different TLDs, ".com" and ".COM"). Or, if you want something outside of the DNS, what ICANN should do about the RPKI "global trust anchor", i.e., whether the RPKI tree should be a singly-rooted tree originating at IANA as indicated by the IAB or a forest of 5 (or 6) trees originating at each of the RIRs (plus IANA) as the RIRs would appear to prefer at this time. If you've read this far, you might worry about your own sanity... :). Regards, -drc (ICANN CTO, but speaking only for myself) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bzs at world.std.com Fri Oct 24 04:41:39 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 24 Oct 2014 00:41:39 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <54495D07.3040405@satchell.net> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> Message-ID: <21577.55427.300064.883007@world.std.com> All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts. Set the location of the pid file, set the path of the executable, set the command line flags/options, maybe change some flags/options based on some options in another file like /etc/sysconfig/daemon_name (also shell commands which are just executed inline), then the start/stop/reload/restart/status case statements. And the dependencies of course. It really could just be config files like xinetd or logrotate except for a few hard cases where you could have a "run this script" attribute. -- -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 oscar.vives at gmail.com Fri Oct 24 07:35:10 2014 From: oscar.vives at gmail.com (Tei) Date: Fri, 24 Oct 2014 09:35:10 +0200 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <21577.55427.300064.883007@world.std.com> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> Message-ID: I pled the Linux people to stay inside the unix philosophy to use text files. Low newbies like me learn from reading config files, and fix thing by reading log files, tryiing to make some sense of the error messages there, and using the most suspicious line as the handle to google for a solution (that is often some stackoverflow article, or some forum posts). I dismay after the idea of somebody replacing all that text by a binary that spouts "the service stoped running" or that corrupt, because some buffer was not flush when the kerfukle happened. Even if going to binary gives a extra 20% speed, I think speed is important but not that important. I plead save the discoverability, learn-bility, debug-ness of text (even text scripts) over mysterious binary blobs elfs generating mysterious binary blobs journals. If they nerf text files, is like they nerf Google for me, and my ability to maintain and configure systems. -- -- ℱin del ℳensaje. From jwininger at ifncom.net Fri Oct 24 14:07:18 2014 From: jwininger at ifncom.net (James Wininger) Date: Fri, 24 Oct 2014 14:07:18 +0000 Subject: NOC Calendar Message-ID: Does anyone on the list have a reference to a good "NOC" calendar? What I mean by that is a calendar that is view only for the NOC, but looks "good" on a larger LCD panel display. Ideally it would automatically rotate on a given schedule (say 6am), and then show only that days scheduled events, there would be no need for the NOC to interact with the calendar, just consume the data. Perhaps it would be color coded to show "DWDM work", vs MPLS work, or even "new installs". But the idea is that the NOC would have readily accessible "view only" at a glance. They would not have to load up outlook, go to calendar, select the MPLS, install etc to see what work is happening. -- Jim Wininger From lowen at pari.edu Fri Oct 24 14:31:36 2014 From: lowen at pari.edu (Lamar Owen) Date: Fri, 24 Oct 2014 10:31:36 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <544A62C8.7010809@pari.edu> On 10/24/2014 03:35 AM, Tei wrote: > I pled the Linux people to stay inside the unix philosophy to use text files. > > You do realize that the systemd config files are still text, right? As to the binary journal, well, by default RHEL 7 (and rebuilds) do at least mirror the journal output to syslog, so /var/log/messages and friends are still there, in plain text. I just verified this on my CentOS 7 evaluation server; yep, /var/log/messages and friends still there and still being used. As to systemd being a big binary, well, the typical initscript is being run by a binary also, even if it is somewhat smaller, and as shellshock shows that still has an attack surface. The systemd config files are much easier to understand than the typical initscript (and since the 'functions' most distributions provide are directly sourced, you need to include that code as well) is, by a very large margin. I'm not thrilled by this change, but after stepping back and looking over all the various systems I've dealt with over the last 25+ years it's honestly not as big of a change as some of the things I've seen (and my experiences include VMS and a number of Unix variants, including Xenix, Irix, SunOS/Solaris, and Domain/OS. And don't get me started on the various CLI's for various switch and router vendors, or I'll throw some Proteon gear your way.....). And while I should be able to enjoy a better desktop experience (I have used Linux as my primary desktop for 17 years), I can also see the server-side uses for the systemd approach, most of which have to do with highly dynamic cloud-style systems (and I'm thinking private cloud, not public). I can see how being load-responsive and rapidly spinning up compute resources as needed and for only as long as needed could help reduce my cost of power; spread out to millions of servers (like Google or Facebook) and the energy savings could be very significant. Much like how package delivery companies plan routes to use only right-hand turns to save megabucks per year on fuel costs. From tknchris at gmail.com Fri Oct 24 14:38:41 2014 From: tknchris at gmail.com (chris) Date: Fri, 24 Oct 2014 10:38:41 -0400 Subject: NOC Calendar In-Reply-To: References: Message-ID: I was looking into something like this a while back and one thing that didnt seem to exist but I thought would be cool is if you could have a x86 box or appliance that could take video output of lets say a couple virtual machines and encode it into a standard TV signal so your average TV with a builtin tuner and have each VM's display encoded into a different TV channel. This way you could throw up TV's everywhere and easily change whats displayed at any time without having to have devices plugged into every TV. If this already exists or someone has built anything like this I would love to hear about it. - chris On Fri, Oct 24, 2014 at 10:07 AM, James Wininger wrote: > Does anyone on the list have a reference to a good "NOC" calendar? What I > mean by that is a calendar that is view only for the NOC, but looks "good" > on a larger LCD panel display. > > Ideally it would automatically rotate on a given schedule (say 6am), and > then show only that days scheduled events, there would be no need for the > NOC to interact with the calendar, just consume the data. > > Perhaps it would be color coded to show "DWDM work", vs MPLS work, or even > "new installs". But the idea is that the NOC would have readily accessible > "view only" at a glance. They would not have to load up outlook, go to > calendar, select the MPLS, install etc to see what work is happening. > > > -- > Jim Wininger > > From chip at 2bithacker.net Fri Oct 24 14:42:52 2014 From: chip at 2bithacker.net (Chip Marshall) Date: Fri, 24 Oct 2014 10:42:52 -0400 Subject: inexpensive KVMoIP In-Reply-To: References: Message-ID: <20141024144252.GB2179@2bithacker.net> On 2014-10-23, Jared Mauch sent: > Having recently encountered a problem with a machine, I’m > looking for an inexpensive KVMoIP device to place within a > facility to take VGA/USB Keyboard for a single host scale. > Ideally something that can be properly placed on the internet, > but that’s not a showstopper. > > If you’re willing to loan me one for a week or two as well, > let me know too so I can ship it to the site and recover my > machine. I've used Lantronix Spiders in the past, they're not bad. I'm curious if anyone knows of one that doesn't use Java for the client though. With things like NoVNC and Guacamole out there now, it seems like a HTML5 based remote KVM should be possible and not a nightmare to work with. -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From jim at reptiles.org Fri Oct 24 15:10:50 2014 From: jim at reptiles.org (Jim Mercer) Date: Fri, 24 Oct 2014 11:10:50 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <21577.55427.300064.883007@world.std.com> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> Message-ID: <20141024151050.GA42095@reptiles.org> On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote: > All those init.d scripts do about 95% the same thing, all hacked > together in shell. Most of them are probably just slightly edited > versions of some few paleo-scripts. in FreeBSD, the bulk of the rc.d scripts are basically the same format, inhaling a standardized library of functions, populating some variables, maybe adding a few custom functions, then jumping to "main". all largely driven off variables which have preset defaults in /etc/default/rc.conf, and over-ridden by /etc/rc.conf. something i saw in various linux systems, which i now see moving into FreeBSD, is the concept of the .d config directory, where the files in /etc/myapp.d are effectively concatenated to /etc/myapp.conf. this is quite nice from a sysadmin perspective, as you can set defaults in /etc/myapp.conf, and then over-ride them with server/environmental specific (and appropriately named) files in /etc/myapp.d/.... --jim -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From john.sweeting at gmail.com Fri Oct 24 15:23:38 2014 From: john.sweeting at gmail.com (John Sweeting) Date: Fri, 24 Oct 2014 11:23:38 -0400 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson wrote: > On 2014-10-23 12:33, Christopher Morrow wrote: > > Sounds like you want to see the rirs make sure they get rpki work >> dine and widely available with the least encumbrances on the network >> operator community as possible. >> > > Or focus on more short/intermediate term returns like fortifying all the > existing systems and automating processes that are already deployed and > focus on ROI of members and operational buffers required by the community > _today. E.g., IRR training and investment rather than RPKI, which this > thread began with. > makes perfect sense to focus on validating existing systems such as IRR. Seems like very low hanging fruit with a lot of benefit and a good ROI > > I'd continue and say in-addr.arpa or the like for resource certification > because RPKI is so ugly, silly without a single root aligned with number > resource allocations, etc.., but that'd require response cycles I'm not > going to spend there. > > Did you see wes's slides / talk at the last nanog? >> > > I did (after). > > Aside, I understand why the ARIN board did what they did with the RPA and > I don't blame them -- it seemed well considered to me, but that's just me. > > Reminded of Taleb's "Fat Tony" quote [paraphrased]: If the pilot ain't on > the plane, you probably don't want to get on it, > > -danny > > > > > > > > From svoll.voip at gmail.com Fri Oct 24 15:27:35 2014 From: svoll.voip at gmail.com (Scott Voll) Date: Fri, 24 Oct 2014 08:27:35 -0700 Subject: Microsoft DNS issue Message-ID: we are seeing two of Microsofts DNS servers are giving out Private IP's. Any idea who to contact to get it fixed? Thanks Scott “Two of the authoritative servers for partners.extranet.microsoft.com are giving unreachable private addresses for that domain” ##Query of dns11 gives unreachable private addresses [ ~]$ dig @*dns11.one.microsoft.com partners.extranet.microsoft.com * ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> @ dns11.one.microsoft.com partners.extranet.microsoft.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6928 ;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. IN A ;; ANSWER SECTION: partners.extranet.microsoft.com. 9 IN A 10.251.94.19 partners.extranet.microsoft.com. 9 IN A 10.251.94.18 partners.extranet.microsoft.com. 9 IN A 10.251.67.137 partners.extranet.microsoft.com. 9 IN A 10.251.67.4 partners.extranet.microsoft.com. 9 IN A 10.251.58.95 partners.extranet.microsoft.com. 9 IN A 10.251.172.137 partners.extranet.microsoft.com. 9 IN A 10.251.172.136 partners.extranet.microsoft.com. 9 IN A 10.147.87.135 partners.extranet.microsoft.com. 9 IN A 10.251.26.13 partners.extranet.microsoft.com. 9 IN A 10.251.58.94 partners.extranet.microsoft.com. 9 IN A 10.251.172.135 partners.extranet.microsoft.com. 9 IN A 10.251.174.149 partners.extranet.microsoft.com. 9 IN A 10.147.63.134 partners.extranet.microsoft.com. 9 IN A 10.147.63.135 partners.extranet.microsoft.com. 9 IN A 10.251.26.14 partners.extranet.microsoft.com. 9 IN A 10.147.88.134 partners.extranet.microsoft.com. 9 IN A 10.147.63.136 partners.extranet.microsoft.com. 9 IN A 10.251.168.246 partners.extranet.microsoft.com. 9 IN A 10.251.58.97 partners.extranet.microsoft.com. 9 IN A 10.251.168.247 partners.extranet.microsoft.com. 9 IN A 10.251.58.96 ;; Query time: 167 msec ;; SERVER: 94.245.124.49#53(94.245.124.49) ;; WHEN: Thu Oct 23 09:01:16 PDT 2014 ;; MSG SIZE rcvd: 396 ##Query of dns13 gives unreachable private addresses [ ~]$ dig @*dns13.one.microsoft.com partners.extranet.microsoft.com * ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> @ dns13.one.microsoft.com partners.extranet.microsoft.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47872 ;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. IN A ;; ANSWER SECTION: partners.extranet.microsoft.com. 177 IN A 10.251.67.4 partners.extranet.microsoft.com. 177 IN A 10.251.168.246 partners.extranet.microsoft.com. 177 IN A 10.251.58.97 partners.extranet.microsoft.com. 177 IN A 10.251.168.247 partners.extranet.microsoft.com. 177 IN A 10.251.58.96 partners.extranet.microsoft.com. 177 IN A 10.251.94.19 partners.extranet.microsoft.com. 177 IN A 10.251.94.18 partners.extranet.microsoft.com. 177 IN A 10.251.174.149 partners.extranet.microsoft.com. 177 IN A 10.147.63.136 partners.extranet.microsoft.com. 177 IN A 10.251.58.95 partners.extranet.microsoft.com. 177 IN A 10.251.172.137 partners.extranet.microsoft.com. 177 IN A 10.251.172.136 partners.extranet.microsoft.com. 177 IN A 10.147.87.135 partners.extranet.microsoft.com. 177 IN A 10.251.26.13 partners.extranet.microsoft.com. 177 IN A 10.251.58.94 partners.extranet.microsoft.com. 177 IN A 10.251.172.135 partners.extranet.microsoft.com. 177 IN A 10.251.67.137 partners.extranet.microsoft.com. 177 IN A 10.147.63.134 partners.extranet.microsoft.com. 177 IN A 10.147.63.135 partners.extranet.microsoft.com. 177 IN A 10.251.26.14 partners.extranet.microsoft.com. 177 IN A 10.147.88.134 ;; Query time: 16 msec ;; SERVER: 65.55.31.17#53(65.55.31.17) ;; WHEN: Thu Oct 23 09:01:28 PDT 2014 ;; MSG SIZE rcvd: 396 From houdini+nanog at clanspum.net Fri Oct 24 16:10:24 2014 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Fri, 24 Oct 2014 11:10:24 -0500 Subject: Paging someone at Savvis [AS 3561] In-Reply-To: <20141023181045.GF11519@clanspum.net> References: <20141023181045.GF11519@clanspum.net> Message-ID: <20141024161024.GI11519@clanspum.net> Bill Weiss(houdini+nanog at clanspum.net)@Thu, Oct 23, 2014 at 01:10:45PM -0500: > I'd like to talk to someone with clue about open NTPd on a router of > yours. Normal support channels are totally failing me. I found someone via the list. Thank you to those who reached out! -- Bill Weiss From mhuff at ox.com Fri Oct 24 16:48:01 2014 From: mhuff at ox.com (Matthew Huff) Date: Fri, 24 Oct 2014 16:48:01 +0000 Subject: Prefix withdrawals in Europe/Russia Message-ID: BGPMon has been sending out alerts this morning starting around 15:14 UTC about our 129.77.0.0/16 prefix. None of our BGP peers have flapped, and according to the alert, it appears limited to: Netherlands Sweden Kuwait Italy United Kingdom Russia Liechtenstein I haven't seen anything on nanog or outages list, anyone know what's going on? From tim at pelican.org Fri Oct 24 16:53:37 2014 From: tim at pelican.org (Tim Franklin) Date: Fri, 24 Oct 2014 17:53:37 +0100 (BST) Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <21577.55427.300064.883007@world.std.com> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> Message-ID: <1010238976.28194.1414169617545.JavaMail.zimbra@pelican.org> > All those init.d scripts do about 95% the same thing, all hacked > together in shell. Most of them are probably just slightly edited > versions of some few paleo-scripts. > > Set the location of the pid file, set the path of the executable, set > the command line flags/options, maybe change some flags/options based > on some options in another file like /etc/sysconfig/daemon_name (also > shell commands which are just executed inline), then the > start/stop/reload/restart/status case statements. And the dependencies > of course. > > It really could just be config files like xinetd or logrotate except > for a few hard cases where you could have a "run this script" > attribute. Replacing "run these scripts in the right order" with a config-driven "service manager" sounds like a sensible development. (Not necessarily the One True Way, but certainly an option). Pulling complicated things like chroot, capabilities etc into one place, getting them right, and then letting services specify what they want, rather than everyone having to re-invent the same shell scripts sounds like it would encourage use of those features. I can even see some more advanced functionality to specify checks / frequencies for "is this service still running / alive" that effectively moves a lot of watchdog functionality into the "service manager". I'm somewhat confused (without reading the implementation details, just conceptually) as to why the "service manager" is also providing DHCP client, SNTP client, virtual consoles, session management... I can completely understand why the "do one thing" crowd are taking objection to that. Regards, Tim. From jared at puck.nether.net Fri Oct 24 17:31:15 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 24 Oct 2014 13:31:15 -0400 Subject: NOC Calendar In-Reply-To: References: Message-ID: <2679E0B4-F9B0-4825-83F3-65542B859D16@puck.nether.net> > On Oct 24, 2014, at 10:38 AM, chris wrote: > > I was looking into something like this a while back and one thing that > didnt seem to exist but I thought would be cool is if you could have a x86 > box or appliance that could take video output of lets say a couple virtual > machines and encode it into a standard TV signal so your average TV with a > builtin tuner and have each VM's display encoded into a different TV > channel. This way you could throw up TV's everywhere and easily change > whats displayed at any time without having to have devices plugged into > every TV. > > If this already exists or someone has built anything like this I would love > to hear about it. We have large screens in our NOC but these are mostly not used as the NOC operators have the same displays on their multiple monitors at desk. This all depends on what ones use case is and the size/scale which is feasible in your space. Having a proper procedure (I think we use WebcalNG or something similar) which emails out reminders of each bit of scheduled work, emergency or not to remind the people of what is occurring is seen as easier. There is also a “status page” where well known ongoing issues (e.g.: cable cuts) can be posted. This is on the big screens, so people coming on-shift can see them as they sit down. Hope this helps, - Jared From brunner at nic-naa.net Fri Oct 24 18:07:47 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 24 Oct 2014 11:07:47 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: References: <54497E03.5020207@nic-naa.net> Message-ID: <544A9573.3000700@nic-naa.net> On 10/23/14 7:27 PM, David Conrad wrote: >> >in other words, the bc and ispc were, and for the most part, imho, remain captive properties of the intellectual property constituency. > Here, Eric is suggesting the intellectual property folks are driving policy issues on behalf of the folks interested in security/stability of e-commerce and as well as ISPs and connectivity providers. I have no reason to doubt Eric's opinion as I've not been involved enough in that part of ICANN and he has. > somethings get lost in translation. even the best of translations. i suggest that the agenda of the intellectual property constituency is the agenda of business and internet service provider constituencies, as measured (in 2008) by staff summary of policy initiatives and votes on policy by the constituencies of the gnso, due to the very high correlations of the constituency votes of record, but it could all be mere, though persistent, coincidence. a nuance is whether the accuracy of whois data (a problem dave crocker and i and others tried to fix at the los angeles icann meeting in november 2001, and which, as hordes of the undead, lives on and on and on) is what is generally meant by "security and stability", or if the value of accuracy of whois data has significant value to parties other than the intellectual property constituency. were the oarc meeting not held, by mere coincidence of course, in a particular hotel in los angeles last week, fewer people with operational roles might have been present. the protocol supporting organization tired of having a voting responsibility on the icann board and got the bylaws changed in 2003 to eliminate itself as a supporting organization holding voting seats on the icann board and created a technical advisory body tasked to periodically provide non-voting persons to offer technical advice to the icann board. i suppose a choice that addresses the problem warren noted is to ask if there is a continued need for operators-or-whatever-as-a-voting-body within the gnso. as much as i participated in the gnso reform program (which may have simply improved some of the ornamental decoration and changed some names from "constituencies" to "stakeholder groups" without changing the balance of forces david noted -- trademark protection vs volume sales -- and would prefer to see the ispcp develop a broader agenda than mere marks protection), taking a step back i'm no longer convinced that operational issues, and therefore operators, have any place, usefully, in the generic domain name supporting organization. eric From cscora at apnic.net Fri Oct 24 18:11:52 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Oct 2014 04:11:52 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201410241811.s9OIBqdM003661@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, TRNOG, 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 Oct, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 516410 Prefixes after maximum aggregation: 199601 Deaggregation factor: 2.59 Unique aggregates announced to Internet: 253017 Total ASes present in the Internet Routing Table: 48396 Prefixes per ASN: 10.67 Origin-only ASes present in the Internet Routing Table: 36301 Origin ASes announcing only one prefix: 16347 Transit ASes present in the Internet Routing Table: 6157 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 118 Max AS path prepend of ASN ( 55644) 111 Prefixes from unregistered ASNs in the Routing Table: 1780 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 7724 Number of 32-bit ASNs visible in the Routing Table: 5938 Prefixes from 32-bit ASNs in the Routing Table: 21106 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 339 Number of addresses announced to Internet: 2712404644 Equivalent to 161 /8s, 172 /16s and 2 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176609 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 127195 Total APNIC prefixes after maximum aggregation: 36794 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 131148 Unique aggregates announced from the APNIC address blocks: 53256 APNIC Region origin ASes present in the Internet Routing Table: 4978 APNIC Prefixes per ASN: 26.35 APNIC Region origin ASes announcing only one prefix: 1189 APNIC Region transit ASes present in the Internet Routing Table: 851 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 118 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1137 Number of APNIC addresses announced to Internet: 736357984 Equivalent to 43 /8s, 227 /16s and 238 /24s Percentage of available APNIC address space announced: 86.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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, 150/8, 153/8, 163/8, 171/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: 171808 Total ARIN prefixes after maximum aggregation: 85426 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173635 Unique aggregates announced from the ARIN address blocks: 81287 ARIN Region origin ASes present in the Internet Routing Table: 16395 ARIN Prefixes per ASN: 10.59 ARIN Region origin ASes announcing only one prefix: 6105 ARIN Region transit ASes present in the Internet Routing Table: 1692 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 235 Number of ARIN addresses announced to Internet: 1052746688 Equivalent to 62 /8s, 191 /16s and 163 /24s Percentage of available ARIN address space announced: 55.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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125553 Total RIPE prefixes after maximum aggregation: 63688 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 131038 Unique aggregates announced from the RIPE address blocks: 82811 RIPE Region origin ASes present in the Internet Routing Table: 17792 RIPE Prefixes per ASN: 7.36 RIPE Region origin ASes announcing only one prefix: 8189 RIPE Region transit ASes present in the Internet Routing Table: 2906 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3147 Number of RIPE addresses announced to Internet: 691970180 Equivalent to 41 /8s, 62 /16s and 160 /24s Percentage of available RIPE address space announced: 100.6 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58770 Total LACNIC prefixes after maximum aggregation: 10794 LACNIC Deaggregation factor: 5.44 Prefixes being announced from the LACNIC address blocks: 67543 Unique aggregates announced from the LACNIC address blocks: 30607 LACNIC Region origin ASes present in the Internet Routing Table: 2360 LACNIC Prefixes per ASN: 28.62 LACNIC Region origin ASes announcing only one prefix: 650 LACNIC Region transit ASes present in the Internet Routing Table: 470 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1362 Number of LACNIC addresses announced to Internet: 171410432 Equivalent to 10 /8s, 55 /16s and 132 /24s Percentage of available LACNIC address space announced: 102.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11876 Total AfriNIC prefixes after maximum aggregation: 2853 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 12707 Unique aggregates announced from the AfriNIC address blocks: 4750 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 17.29 AfriNIC Region origin ASes announcing only one prefix: 214 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 57 Number of AfriNIC addresses announced to Internet: 59635968 Equivalent to 3 /8s, 141 /16s and 249 /24s Percentage of available AfriNIC address space announced: 59.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2949 11584 926 Korea Telecom 17974 2817 903 77 PT Telekomunikasi Indonesia 7545 2423 336 124 TPG Telecom Limited 4755 1919 412 189 TATA Communications formerly 9829 1670 1322 37 National Internet Backbone 9808 1477 6639 15 Guangdong Mobile Communicatio 4808 1409 2204 420 CNCGROUP IP network China169 9583 1359 111 559 Sify Limited 9498 1307 333 91 BHARTI Airtel Ltd. 7552 1187 1066 12 Viettel Corporation 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 2896 3688 51 BellSouth.net Inc. 22773 2839 2940 142 Cox Communications Inc. 18566 2046 379 182 MegaPath Corporation 7029 1943 1957 312 Windstream Communications Inc 20115 1810 1790 479 Charter Communications 4323 1636 1052 410 tw telecom holdings, inc. 6983 1540 867 250 ITC^Deltacom 30036 1485 309 612 Mediacom Communications Corp 701 1426 11266 710 MCI Communications Services, 22561 1303 408 237 CenturyTel Internet Holdings, 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 1840 297 352 TELLCOM ILETISIM HIZMETLERI A 20940 1492 577 1101 Akamai International B.V. 8402 1410 544 15 OJSC "Vimpelcom" 31148 1044 45 21 Freenet Ltd. 13188 1037 100 29 TOV "Bank-Inform" 8551 961 372 41 Bezeq International-Ltd 6849 835 356 26 JSC "Ukrtelecom" 6830 782 2339 435 Liberty Global Operations B.V 12479 751 785 96 France Telecom Espana SA 9198 671 346 30 JSC Kazakhtelecom 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 3008 487 241 Telmex Colombia S.A. 28573 2642 2315 107 NET Servi�os de Comunica��o S 6147 1783 374 30 Telefonica del Peru S.A.A. 7303 1765 1171 241 Telecom Argentina S.A. 8151 1481 3017 433 Uninet S.A. de C.V. 6503 1139 434 61 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 913 2325 35 Tim Celular S.A. 27947 912 130 51 Telconet S.A 3816 890 383 146 COLOMBIA TELECOMUNICACIONES S 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 1192 958 13 TE-AS 24863 948 280 26 Link Egypt (Link.NET) 6713 678 760 38 Office National des Postes et 36992 343 824 28 ETISALAT MISR 24835 308 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 246 22 17 Cote d'Ivoire Telecom 37054 231 19 6 Data Telecom Service 15706 186 17 6 Sudatel (Sudan Telecom Co. Lt 37457 180 160 4 Telkom SA Ltd. 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 10620 3008 487 241 Telmex Colombia S.A. 4766 2949 11584 926 Korea Telecom 6389 2896 3688 51 BellSouth.net Inc. 22773 2839 2940 142 Cox Communications Inc. 17974 2817 903 77 PT Telekomunikasi Indonesia 28573 2642 2315 107 NET Servi�os de Comunica��o S 7545 2423 336 124 TPG Telecom Limited 18566 2046 379 182 MegaPath Corporation 7029 1943 1957 312 Windstream Communications Inc 4755 1919 412 189 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2896 2845 BellSouth.net Inc. 17974 2817 2740 PT Telekomunikasi Indonesia 22773 2839 2697 Cox Communications Inc. 28573 2642 2535 NET Servi�os de Comunica��o S 7545 2423 2299 TPG Telecom Limited 4766 2949 2023 Korea Telecom 18566 2046 1864 MegaPath Corporation 6147 1783 1753 Telefonica del Peru S.A.A. 4755 1919 1730 TATA Communications formerly 9829 1670 1633 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:12 /10:31 /11:90 /12:262 /13:500 /14:1006 /15:1713 /16:13040 /17:7133 /18:11862 /19:24619 /20:35303 /21:37342 /22:55162 /23:48364 /24:277027 /25:1101 /26:1060 /27:709 /28:14 /29:19 /30:11 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2061 2839 Cox Communications Inc. 18566 2001 2046 MegaPath Corporation 6389 1676 2896 BellSouth.net Inc. 6147 1347 1783 Telefonica del Peru S.A.A. 30036 1332 1485 Mediacom Communications Corp 6983 1226 1540 ITC^Deltacom 7029 1172 1943 Windstream Communications Inc 34984 1160 1840 TELLCOM ILETISIM HIZMETLERI A 11492 1147 1197 CABLE ONE, INC. 8402 1087 1410 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1355 2:679 3:3 4:17 5:1176 6:21 8:770 12:1854 13:4 14:1173 15:17 16:2 17:42 18:21 20:51 23:945 24:1778 27:1817 31:1332 32:40 33:2 34:5 36:154 37:1803 38:1008 39:13 40:233 41:2906 42:260 43:550 44:18 45:81 46:2062 47:28 49:740 50:790 52:12 54:53 55:3 56:10 57:32 58:1141 59:644 60:435 61:1716 62:1265 63:1835 64:4423 65:2271 66:4193 67:2027 68:1093 69:3259 70:873 71:478 72:1985 74:2605 75:378 76:410 77:1606 78:1012 79:764 80:1323 81:1283 82:791 83:659 84:725 85:1354 86:427 87:1185 88:497 89:1801 90:138 91:5801 92:786 93:1642 94:2035 95:1305 96:424 97:340 98:1100 99:48 100:65 101:734 103:5905 104:477 105:155 106:181 107:651 108:580 109:2000 110:1048 111:1423 112:720 113:909 114:800 115:1154 116:1154 117:999 118:1544 119:1376 120:740 121:967 122:2209 123:1673 124:1446 125:1539 128:627 129:386 130:369 131:925 132:435 133:165 134:322 135:81 136:324 137:314 138:381 139:200 140:223 141:413 142:602 143:454 144:509 145:111 146:679 147:561 148:1031 149:407 150:503 151:634 152:477 153:240 154:398 155:580 156:380 157:330 158:280 159:923 160:330 161:604 162:1810 163:405 164:648 165:672 166:363 167:688 168:1121 169:122 170:1425 171:188 172:60 173:1634 174:708 175:612 176:1537 177:3675 178:2078 179:811 180:1764 181:1782 182:1661 183:702 184:710 185:2229 186:2962 187:1687 188:2010 189:1529 190:7908 191:780 192:7732 193:5558 194:4074 195:3616 196:1633 197:734 198:5277 199:5487 200:6485 201:2907 202:9129 203:9043 204:4704 205:2660 206:3088 207:2970 208:3923 209:3760 210:3316 211:1856 212:2411 213:2164 214:857 215:86 216:5624 217:1707 218:623 219:391 220:1376 221:794 222:481 223:696 End of report From mehmet at akcin.net Fri Oct 24 19:06:39 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 24 Oct 2014 14:06:39 -0500 Subject: Microsoft DNS issue In-Reply-To: References: Message-ID: <0DE5C4CF-B28A-4344-B08B-43A4B641FA8A@akcin.net> Replying offlist. Mehmet > On Oct 24, 2014, at 10:27 AM, Scott Voll wrote: > > we are seeing two of Microsofts DNS servers are giving out Private IP's. > > Any idea who to contact to get it fixed? > > Thanks > > Scott > > > “Two of the authoritative servers for partners.extranet.microsoft.com are > giving unreachable private addresses for that domain” > > > > ##Query of dns11 gives unreachable private addresses > > [ ~]$ dig @*dns11.one.microsoft.com > partners.extranet.microsoft.com * > > > > ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> @ > dns11.one.microsoft.com partners.extranet.microsoft.com > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6928 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4000 > > ;; QUESTION SECTION: > > ;partners.extranet.microsoft.com. IN A > > > > ;; ANSWER SECTION: > > partners.extranet.microsoft.com. 9 IN A 10.251.94.19 > > partners.extranet.microsoft.com. 9 IN A 10.251.94.18 > > partners.extranet.microsoft.com. 9 IN A 10.251.67.137 > > partners.extranet.microsoft.com. 9 IN A 10.251.67.4 > > partners.extranet.microsoft.com. 9 IN A 10.251.58.95 > > partners.extranet.microsoft.com. 9 IN A 10.251.172.137 > > partners.extranet.microsoft.com. 9 IN A 10.251.172.136 > > partners.extranet.microsoft.com. 9 IN A 10.147.87.135 > > partners.extranet.microsoft.com. 9 IN A 10.251.26.13 > > partners.extranet.microsoft.com. 9 IN A 10.251.58.94 > > partners.extranet.microsoft.com. 9 IN A 10.251.172.135 > > partners.extranet.microsoft.com. 9 IN A 10.251.174.149 > > partners.extranet.microsoft.com. 9 IN A 10.147.63.134 > > partners.extranet.microsoft.com. 9 IN A 10.147.63.135 > > partners.extranet.microsoft.com. 9 IN A 10.251.26.14 > > partners.extranet.microsoft.com. 9 IN A 10.147.88.134 > > partners.extranet.microsoft.com. 9 IN A 10.147.63.136 > > partners.extranet.microsoft.com. 9 IN A 10.251.168.246 > > partners.extranet.microsoft.com. 9 IN A 10.251.58.97 > > partners.extranet.microsoft.com. 9 IN A 10.251.168.247 > > partners.extranet.microsoft.com. 9 IN A 10.251.58.96 > > > > ;; Query time: 167 msec > > ;; SERVER: 94.245.124.49#53(94.245.124.49) > > ;; WHEN: Thu Oct 23 09:01:16 PDT 2014 > > ;; MSG SIZE rcvd: 396 > > > > ##Query of dns13 gives unreachable private addresses > > [ ~]$ dig @*dns13.one.microsoft.com > partners.extranet.microsoft.com * > > > > ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> @ > dns13.one.microsoft.com partners.extranet.microsoft.com > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47872 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4000 > > ;; QUESTION SECTION: > > ;partners.extranet.microsoft.com. IN A > > > > ;; ANSWER SECTION: > > partners.extranet.microsoft.com. 177 IN A 10.251.67.4 > > partners.extranet.microsoft.com. 177 IN A 10.251.168.246 > > partners.extranet.microsoft.com. 177 IN A 10.251.58.97 > > partners.extranet.microsoft.com. 177 IN A 10.251.168.247 > > partners.extranet.microsoft.com. 177 IN A 10.251.58.96 > > partners.extranet.microsoft.com. 177 IN A 10.251.94.19 > > partners.extranet.microsoft.com. 177 IN A 10.251.94.18 > > partners.extranet.microsoft.com. 177 IN A 10.251.174.149 > > partners.extranet.microsoft.com. 177 IN A 10.147.63.136 > > partners.extranet.microsoft.com. 177 IN A 10.251.58.95 > > partners.extranet.microsoft.com. 177 IN A 10.251.172.137 > > partners.extranet.microsoft.com. 177 IN A 10.251.172.136 > > partners.extranet.microsoft.com. 177 IN A 10.147.87.135 > > partners.extranet.microsoft.com. 177 IN A 10.251.26.13 > > partners.extranet.microsoft.com. 177 IN A 10.251.58.94 > > partners.extranet.microsoft.com. 177 IN A 10.251.172.135 > > partners.extranet.microsoft.com. 177 IN A 10.251.67.137 > > partners.extranet.microsoft.com. 177 IN A 10.147.63.134 > > partners.extranet.microsoft.com. 177 IN A 10.147.63.135 > > partners.extranet.microsoft.com. 177 IN A 10.251.26.14 > > partners.extranet.microsoft.com. 177 IN A 10.147.88.134 > > > > ;; Query time: 16 msec > > ;; SERVER: 65.55.31.17#53(65.55.31.17) > > ;; WHEN: Thu Oct 23 09:01:28 PDT 2014 > > ;; MSG SIZE rcvd: 396 From bzs at world.std.com Fri Oct 24 19:13:48 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 24 Oct 2014 15:13:48 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: References: <54497E03.5020207@nic-naa.net> Message-ID: <21578.42220.902698.749301@world.std.com> Well, that was pure gold, David. If you didn't read it and think you might have the slightest interest in what's going on with ICANN stuff: Read It. I'll mildly dispute the point about registration services (aka WHOIS). Though I've no doubt someone out there imagines improving the quality of the database would help with spam I tend to doubt it. I believe this never-ending quest for more reliable domain registration data is being driven by intellectual property lawyers to lower the cost of serving those they see as infringers either by domain or web site content. I know this both from sitting in on the IPC meetings occasionally and talking to lawyers at ICANN many of whom seem to believe that while they should be paid $300/hour for their time that everyone else should endeavor to make their job easier and less error-prone for free. I'd imagine there's something deeper going on there which I don't fully understand like they have trouble (profitably) billing clients for tracking down the target of their lawsuits and see it as an aspect of discovery they'd just as soon eliminate by shifting the burden to the registrars (and general public of course) et al. FWIW, my suggestion was to put the WHOIS data into the DNS (a new RR perhaps) under the control of whoever manages that DNS record and if someone needs more correct information then perhaps the registrars could provide it (perhaps for a fee) from the sales slips (so to speak.) It's just a sales record, not sure why some are trying to move heaven and earth to idealize the information and access to it. P.S. And of course the new WHOIS proposal involves creating classes of access to go along with improved correctness. So only bona-fide lawyers with paid-up bar dues will be able to get at the info because, you know, lawyers, esq. -b On October 23, 2014 at 19:27 drc at virtualized.org (David Conrad) wrote: > Hi, > > While I'm sure most of the folks on NANOG are fully aware of the myriad of acronyms and Byzantine structures in the ICANN universe (:)), I thought some translation for those not inoculated with ICANNese may be helpful: > > On Oct 23, 2014, at 3:15 PM, Eric Brunner-Williams wrote: > > some history. > > > > at the montevideo icann meeting (september, 2001), there were so few attendees to either the ispc (now ispcp) and the bc (still bc), > > Translated: > > At a meeting in Uruguay in 2001 (one of the 3 times per year meetings ICANN holds all over the world in accordance with its Bylaws requirement to be a global organization and/or the desire of those who came up with the Bylaws to have many fine lunches and dinners in exotic places), very few people attended the working group meetings purportedly chartered for the interests of ISPs (the "ISP Constituency" or ISPC) and the meetings purportedly chartered for typically e-commerce related business interests (the "Business Constituency" or BC). > > For those interested and/or who have morbid curiosity, both of these constituencies have their own web pages: > > ISPCP: http://ispcp.info > BC: http://www.bizconst.org > > The parentheticals note the ISP Constituency was renamed to the "ISP and Connectivity Provider" Constituency (ISPCP) and the Business Constituency is still named the BC. I do not know for sure what the rationale was behind the renaming (I'm guessing it was to increase the number of folks the Constituency would be relevant to). > > > that these two meetings merged. > > You could see this either as a desire to have something like a "joint working group meeting" in IETF parlance or a desire to have a few people in a single room instead of a couple of people in two rooms to try to avoid awkwardness (in my experience, the ISPCP meetings are not particularly well attended -- this may have changed: I haven't been in a while. I can't comment on the BC meetings since I've never been.) > > > at the paris icann meeting (june, 2008) staff presented an analysis of the voting patters of the gnso constituencies > > GNSO: Generic Names Supporting Organization, the folks who care sufficiently deeply about generic top-level domains to go to places like Montevideo and Paris for a week to scream past... err... reach consensus with other individuals who care deeply about generic top-level domains. > > The GNSO is made up of a bunch of Constituencies, of which the ISPCP and BC are two. There are more. > > There are two other Supporting Organizations, the ccNSO for country code TLDs and the ASO, the Addressing Supporting Organization, made up of folks elected by the RIRs. > > > -- to my non-surprise, both the bc and the ispc votes (now ispcp) correlated very highly with the intellectual property constituency, > > Yet another GNSO Constituency: the Intellectual Property Constituency (IPC), focused on trying to protect the interests of Intellectual Property Rights owners in the areas ICANN touches. > > IPC: http://www.ipconstituency.org > > I think it safe to say that much (but not all) of the warfare that goes on at ICANN meetings is between the folks interested in protecting IPR (in this context, trademarks) and folks interested in selling oodles of domain names. > > > and unlike that constituency, originated very little in the way of policy issues for which an eventual vote was recorded. > > I am, in fact, unaware of any policy issues originated out of the ISPCP or BC (but again, I'm not too familiar with these groups). From a purely technical policy perspective, this may be considered to be ... unfortunate. That is, many of the folk on this mailing list undoubtedly have a view on what ICANN does yet those views are not relayed in a way the ICANN community can hear. > > > in other words, the bc and ispc were, and for the most part, imho, remain captive properties of the intellectual property constituency. > > Here, Eric is suggesting the intellectual property folks are driving policy issues on behalf of the folks interested in security/stability of e-commerce and as well as ISPs and connectivity providers. I have no reason to doubt Eric's opinion as I've not been involved enough in that part of ICANN and he has. > > > this could change, but the isps that fund suits need to change the suits they send, the trademark lawyer of eyeball network operator X is not the vp of ops of network operator X. > > Indeed, and I must commend Warren and Eric for caring enough to actually engage in this stuff. While many people in the NANOG/IETF/DNS Operations communities complain about the latest abomination ICANN is inflicting upon the world, there aren't a whole lot of folks from those communities who take the (non-trivial) amount of time to try to understand and address the situation. While I fully understand the rationales for not participating, the lack of strong representation from the technical community does not help in preventing abominations. > > > meanwhile, whois, the udrp, and other bits o' other-people's-business-model take up all the available time. > > UDRP: The "Uniform Domain Name Dispute Resolution Policy" (I do not know why it isn't referenced as the UDNDRP or "udden-drip"). This is the mechanism by which people who believe a domain name is being used abusively can attempt to have that abuse stopped. Folks who have been through UDRP disputes can comment on their view of its effectiveness. > > Examples of "other bits o' other-peope's-business-model" might include stuff like how to improve accuracy in the registration databases so anti-abuse folks can have more hope finding spammers or how culturally/liguistically-identical-but-represented-by-different-Unicode-glyphs strings can be deployed as new top-level domains (by analogy, imagine if the DNS was not case insensitive for LDH labels and the 'fun' that would occur if different organizations were allowed to sell names out of the two different TLDs, ".com" and ".COM"). Or, if you want something outside of the DNS, what ICANN should do about the RPKI "global trust anchor", i.e., whether the RPKI tree should be a singly-rooted tree originating at IANA as indicated by the IAB or a forest of 5 (or 6) trees originating at each of the RIRs (plus IANA) as the RIRs would appear to prefer at this time. > > If you've read this far, you might worry about your own sanity... :). > > Regards, > -drc > (ICANN CTO, but speaking only for myself) > -- -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 brandon at burn.net Fri Oct 24 19:45:30 2014 From: brandon at burn.net (Brandon Applegate) Date: Fri, 24 Oct 2014 15:45:30 -0400 Subject: IGMP (v3) older version querier timer on OSX Message-ID: <6F4D0354-716A-4AFB-9C5B-6B579FC4510C@burn.net> First of all - if there is a better place to ask this, let me know. I simply want to make sure the audience has the technical chops to try to answer the question. So discussions.apple.com / macrumors are out. I’m trying to figure out how OSX is behaving with regard to downgrading sent IGMP messages in the presence of “older” queriers. I.e. if a query is heard from a router (querier) that is v2, start a timer and only speak (IGMP) in v2 until it expires. From the definitions I’ve found of how to calculate this timer - that should be 260 seconds. After this time, assuming we haven’t heard any further v2 queries - we can start speaking v3 again. From my testing (using 10.9 Mavericks and the newest VLC) - this doesn’t happen. From the network side, I’m using a Cisco 3750 with snooping and querier turned on (i.e. not a real mcast router). If I turn these off and reboot, VLC causes IGMP v3 to be sent. If I turn querier back on on my switch - OSX drops down to IGMP v2. It just never seems to bounce back to v3. I think I waited ~ 10 minutes on my last test, and it was still v2. Thanks - and sorry this isn’t about systemd (although I am reading the thread and think it’s a great topic). -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jra at baylink.com Fri Oct 24 20:25:38 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Oct 2014 16:25:38 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Message-ID: <23847049.16.1414182338672.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Loiacono" > > The arguments against systemd that I've seen so far: > > > > 1) It's different so it's bad. > > 2) There's a lot of code, there must be some really bad security > > problems just waiting to happen, so it's bad. > > 3) It doesn't do things the way we've always done them, so it's bad. > > 4) The systemd developers are jerks, so it's bad. > > Hmmm. It seems that list is missing its most important item. > > As an impartial lurker, the primary objection I've seen is: > > 1. "Try to do everything" software is not optimal, and will lead to > heartache. "Try to do everything *inside PID 1*" is the real problem. It is a problem because it violates "do one thing and do it well", and also because it enlarges the privileged attack surface, as made fun of improperly at 2) above. 3) is not an invalid assertion either, and if you think it is, then your systems are pretty bone-stock. 4) is not a *direct* impeachment of the code, but developers who can't work and play well with others are more prone to produce code which also can't. The Unix design philosophy wasn't made up out of thin air; it is the residue of decades of failures, and you flout it at your peril, and systemd flouts it rather badly. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Oct 24 20:26:51 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Oct 2014 16:26:51 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <21575.63481.947211.798330@world.std.com> Message-ID: <27422368.18.1414182411491.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > On October 21, 2014 at 13:44 brunner at nic-naa.net (Eric > Brunner-Williams) wrote: > > > systemd is insanity. > > > > see also smit. > > SMIT! Rhymes with .... For the record, smit is crazy cause AIX isn't really Unix; it's VM with a thin POSIX skin overtop. Very thin in places. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Oct 24 20:29:48 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Oct 2014 16:29:48 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <54495BFD.4010205@pari.edu> Message-ID: <25873572.20.1414182588486.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Lamar Owen" > Speaking from my own experience, the actually relevant and > package-specific guts of the typical initscript could be easily > replaced by a simple text configuration that simply gives: > > 1.) What to start > 2.) When to start it (traditional initscripts work on a linear > timeline > of priority slots; systemd units have more flexibility) > 3.) How to start it (command line options) > > This should not need to be an executable script. This is what systemd > brings to the table (Upstart brought some of this, too). That is a perfectly valid point. We don't dislike systemd because it does that. We dislike it because it doesn't *only* do that. Cheers, -- jr 'see also IPv6' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Oct 24 20:34:12 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Oct 2014 16:34:12 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: Message-ID: <19087857.22.1414182852165.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Jeffrey Ollie" > > If that doesn't suffice, then I suspect it will only require waiting > > a little while until a demonstration of why monolithic integration > > is a bad idea will be provided by someone who is at this moment > > studying the large-and-growing attack surface presented by systemd. > > > > I hope I'm wrong about that. I'm probably not. > > Software is software. I'm sure that bugs (including security bugs) > will be found. Film at 11. Nothing new here. Nope, Jeff; you've entirely missed it: On a non-systemd distribution, the odds are good that a) that bug is in code not running as root nor b) in PID1 where if it locks up it takes the whole box with it, and also c) I can just put my thumb down on that one piece and turn it off; that's almost certainly and almost always not true in systemd. That's what's new here. As I noted in another posting, that Unix Philosophy happened for a reason. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Oct 24 20:41:17 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Oct 2014 16:41:17 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447DF5E.6090402@lugosys.com> Message-ID: <19234509.24.1414183277406.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > On 22-10-2014 17:30, Jeffrey Ollie wrote: > > Hardly. The discussion so far has been weighted very heavily on the > > side of Dana Carvey's "Grumpy Old Man"-style whining. "That's the way > > it was and we liked it!". The people that like systemd (like myself) > > have wisely learned that the people that hate systemd, hate it mostly > > because it's different from what came before and don't want to change. > > There's no way to argue rationally with that. That's not true, Jeff. Nearly all the anti-systemd arguments I have seen have itemized the design features of the package which we don't like, and provided what seem to us to be good and cogent reasons why we don't like those, in many cases backed up with examples of how earlier similar designs failed that way. "Grumpy Old Man" is a strawman argument, and there's no way to argue with that at all: you merely identify it as fallacious and ignore it. And if the same proponent keeps doing it, you demonstrate the sound an idiot makes falling to the bottom of your killfile. Please don't. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From cma at cmadams.net Fri Oct 24 20:41:50 2014 From: cma at cmadams.net (Chris Adams) Date: Fri, 24 Oct 2014 15:41:50 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <23847049.16.1414182338672.JavaMail.root@benjamin.baylink.com> References: <23847049.16.1414182338672.JavaMail.root@benjamin.baylink.com> Message-ID: <20141024204150.GA1267@cmadams.net> Once upon a time, Jay Ashworth said: > "Try to do everything *inside PID 1*" is the real problem. And that is not what systemd is doing; make sure you know what you are complaining about. systemd-the-project != systemd-the-pid-1. PID 1 is responsible for managing services/daemons, and AFAIK that's all systemd's PID 1 does. -- Chris Adams From christopher.morrow at gmail.com Fri Oct 24 21:24:09 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 24 Oct 2014 14:24:09 -0700 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: On Fri, Oct 24, 2014 at 8:23 AM, John Sweeting wrote: > > > On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson wrote: >> >> On 2014-10-23 12:33, Christopher Morrow wrote: >> >>> Sounds like you want to see the rirs make sure they get rpki work >>> dine and widely available with the least encumbrances on the network >>> operator community as possible. >> >> >> Or focus on more short/intermediate term returns like fortifying all the >> existing systems and automating processes that are already deployed and >> focus on ROI of members and operational buffers required by the community >> _today. E.g., IRR training and investment rather than RPKI, which this >> thread began with. > > > makes perfect sense to focus on validating existing systems such as IRR. > Seems like very low hanging fruit with a lot of benefit and a good ROI it seems to me that there are a couple simple issues with IRR data (historically): 1) no authority for it (really, at least in the ARIN region) 2) no common practice of keeping it updated 3) proxy-registration issues (probably part of cleanup and authority issues) 4) lack of widespread use due to the above issues. I was/am hopeful that providing some path from IANA (eventually) on down through RIR to LIR to end-user for 'authority to use' ip resources would help in letting people use the IRR data cleansed of insanity by the data from this path, and then into routers for route filters. The RPKI system looks like the path in question, to me. >> I'd continue and say in-addr.arpa or the like for resource certification >> because RPKI is so ugly, silly without a single root aligned with number >> resource allocations, etc.., but that'd require response cycles I'm not >> going to spend there. >> >>> Did you see wes's slides / talk at the last nanog? >> >> >> I did (after). >> >> Aside, I understand why the ARIN board did what they did with the RPA and >> I don't blame them -- it seemed well considered to me, but that's just me. >> >> Reminded of Taleb's "Fat Tony" quote [paraphrased]: If the pilot ain't on >> the plane, you probably don't want to get on it, >> >> -danny From cidr-report at potaroo.net Fri Oct 24 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Oct 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201410242200.s9OM00Ui091590@wattle.apnic.net> This report has been generated at Fri Oct 24 21:14:12 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-10-14 520223 287580 18-10-14 519535 287740 19-10-14 519823 287817 20-10-14 519853 288043 21-10-14 520379 288857 22-10-14 520506 288922 23-10-14 520878 288938 24-10-14 521614 289328 AS Summary 48634 Number of ASes in routing system 19568 Number of ASes announcing only one prefix 3008 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120110848 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 24Oct14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 522149 289304 232845 44.6% All ASes AS6389 2896 102 2794 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2817 83 2734 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2843 162 2681 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2644 115 2529 95.7% NET Servi�os de Comunica��o S.A.,BR AS6147 1785 167 1618 90.6% Telefonica del Peru S.A.A.,PE AS4766 2950 1333 1617 54.8% KIXS-AS-KR Korea Telecom,KR AS7303 1769 290 1479 83.6% Telecom Argentina S.A.,AR AS9808 1477 54 1423 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1389 25 1364 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1917 609 1308 68.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2440 1177 1263 51.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1811 558 1253 69.2% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1645 412 1233 75.0% TWTC - tw telecom holdings, inc.,US AS9498 1309 108 1201 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2045 867 1178 57.6% MEGAPATH5-US - MegaPath Corporation,US AS7552 1212 52 1160 95.7% VIETEL-AS-AP Viettel Corporation,VN AS6983 1541 388 1153 74.8% ITCDELTA - Earthlink, Inc.,US AS10620 3008 1957 1051 34.9% Telmex Colombia S.A.,CO AS7029 2102 1090 1012 48.1% WINDSTREAM - Windstream Communications Inc,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS34984 1840 927 913 49.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1304 410 894 68.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS56040 891 30 861 96.6% CMNET-GUANGDONG-AP China Mobile communications corporation,CN AS38285 978 131 847 86.6% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4788 1078 244 834 77.4% TMNET-AS-AP TM Net, Internet Service Provider,MY AS24560 1178 350 828 70.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1042 257 785 75.3% FREENET-AS Freenet Ltd.,UA AS4780 1049 274 775 73.9% SEEDNET Digital United Inc.,TW AS26615 898 131 767 85.4% Tim Celular S.A.,BR AS18101 957 196 761 79.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 51814 12582 39232 75.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.220.173.0/24 AS30058 FDCSERVERS - FDCservers.net,US 93.157.184.0/22 AS12714 TI-AS Net By Net Holding LLC,RU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.44.225.0/24 AS13374 HYTL-AS-AP HONGKONG YABOIDC TECHNOLOGY LIMITED,HK 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 104.219.100.0/22 AS39343 ROGERSWEST - Rogers West,CA 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.74.80.0/22 AS20194 SOLTIA Soltia Consulting SL,ES 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.7.160.0/21 AS13703 BROADRIVER-13703 - BroadRiver Communication Corp.,US 199.7.162.0/24 AS22626 -Reserved AS-,ZZ 199.7.167.0/24 AS22626 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.116.212.0/22 AS53704 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 cidr-report at potaroo.net Fri Oct 24 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Oct 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201410242200.s9OM0153091606@wattle.apnic.net> BGP Update Report Interval: 16-Oct-14 -to- 23-Oct-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 208234 4.0% 2263.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS44436 205374 4.0% 8215.0 -- EFFORTEL-AS LLC MyBox,RU 3 - AS9829 176641 3.4% 145.5 -- BSNL-NIB National Internet Backbone,IN 4 - AS45786 153967 3.0% 2199.5 -- HTSNET-AS-ID HTSNET - ISP,ID 5 - AS17974 65455 1.3% 93.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 6 - AS38197 54550 1.1% 54.1 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 7 - AS13682 53623 1.0% 8937.2 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 8 - AS24193 51784 1.0% 224.2 -- SIFY-IN Sify Limited Service Provider India,IN 9 - AS3816 48734 0.9% 84.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 10 - AS7545 46333 0.9% 24.6 -- TPG-INTERNET-AP TPG Telecom Limited,AU 11 - AS34984 38936 0.8% 25.6 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 12 - AS51964 36149 0.7% 160.0 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 13 - AS28573 35171 0.7% 20.9 -- NET Servi�os de Comunica��o S.A.,BR 14 - AS45899 33085 0.6% 54.1 -- VNPT-AS-VN VNPT Corp,VN 15 - AS21491 29767 0.6% 595.3 -- UGANDA-TELECOM Uganda Telecom,UG 16 - AS9583 28872 0.6% 30.1 -- SIFY-AS-IN Sify Limited,IN 17 - AS7552 26868 0.5% 26.6 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS4787 25622 0.5% 70.2 -- ASN-CBN Internet Service Provider,ID 19 - AS9924 22555 0.4% 160.0 -- TFN-TW Taiwan Fixed Network, Telco and Network Service Provider.,TW 20 - AS23342 22232 0.4% 22232.0 -- UNITEDLAYER - Unitedlayer, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23342 22232 0.4% 22232.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 2 - AS13682 53623 1.0% 8937.2 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 3 - AS44436 205374 4.0% 8215.0 -- EFFORTEL-AS LLC MyBox,RU 4 - AS18135 7824 0.1% 7824.0 -- BTV BTV Cable television,JP 5 - AS61039 7455 0.1% 7455.0 -- ZMZ OAO ZMZ,RU 6 - AS32336 7354 0.1% 7354.0 -- IPASS-2 - iPass Incorporated,US 7 - AS43943 13216 0.3% 6608.0 -- KCM KCM SA,BG 8 - AS42932 4539 0.1% 4539.0 -- IPT IPT sp. z o.o.,PL 9 - AS62174 4140 0.1% 4140.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS52355 7750 0.1% 3875.0 -- Jalasoft Corp.,BO 11 - AS2 3858 0.1% 1435.0 -- UDEL-DCN - University of Delaware,US 12 - AS60725 18552 0.4% 3710.4 -- O3B-AS O3b Limited,JE 13 - AS35093 5349 0.1% 2674.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 14 - AS8738 2401 0.1% 2401.0 -- VISA-ISRAEL-AS Israel Credit Cards Ltd,IL 15 - AS30727 2337 0.1% 2337.0 -- SYSLINK syslink operations AG, Basel, Switzerland,CH 16 - AS23752 208234 4.0% 2263.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 17 - AS45786 153967 3.0% 2199.5 -- HTSNET-AS-ID HTSNET - ISP,ID 18 - AS34023 2031 0.0% 2031.0 -- CITYLINE-AS PE Shattah Zia G.Naman,UA 19 - AS3 1992 0.0% 2975.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS61384 5924 0.1% 1974.7 -- NEON-ISP-AS PE Konev Pavel Alekseevich,UA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.61.101.0/24 153843 2.9% AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID AS65001 -- -Private Use AS-,ZZ 2 - 202.70.64.0/21 103319 1.9% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 103307 1.9% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 46.34.144.0/22 70223 1.3% AS44436 -- EFFORTEL-AS LLC MyBox,RU 5 - 62.32.84.0/24 65583 1.2% AS34277 -- ALFA-LTD-AS Alfa Ltd.,RU AS44436 -- EFFORTEL-AS LLC MyBox,RU 6 - 62.32.95.0/24 65570 1.2% AS34277 -- ALFA-LTD-AS Alfa Ltd.,RU AS44436 -- EFFORTEL-AS LLC MyBox,RU 7 - 64.29.130.0/24 22232 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 8 - 192.115.44.0/22 19499 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 9 - 200.34.149.0/24 11672 0.2% AS8151 -- Uninet S.A. de C.V.,MX 10 - 192.58.232.0/24 11023 0.2% AS6629 -- NOAA-AS - NOAA,US 11 - 200.119.160.0/19 10700 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 12 - 190.143.240.0/20 10666 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 13 - 162.249.183.0/24 9905 0.2% AS60725 -- O3B-AS O3b Limited,JE 14 - 190.143.224.0/20 9006 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 15 - 190.143.192.0/19 9001 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 16 - 200.119.152.0/21 8914 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 17 - 185.26.155.0/24 8622 0.2% AS60725 -- O3B-AS O3b Limited,JE 18 - 188.123.160.0/19 8093 0.1% AS47887 -- NEU-AS AL-HADATHEH LIL-ITISALAT WA AL-TECHNOLOGIA CO.,JO 19 - 42.83.48.0/20 7824 0.1% AS18135 -- BTV BTV Cable television,JP 20 - 91.235.169.0/24 7455 0.1% AS61039 -- ZMZ OAO ZMZ,RU 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 baldur.norddahl at gmail.com Fri Oct 24 23:20:58 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 25 Oct 2014 01:20:58 +0200 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: The RIPE IRR is secure. Why not just copy that for the other regions? Baldur From jmasiello at actionet.com Thu Oct 23 15:02:12 2014 From: jmasiello at actionet.com (Jeff Masiello) Date: Thu, 23 Oct 2014 15:02:12 +0000 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <5447E1E3.1010801@privacyrequired.com> References: <5445AD63.7090400@lugosys.com> <66189.1413898830@turing-police.cc.vt.edu> <5447E1E3.1010801@privacyrequired.com> Message-ID: As lurker I just wanted to say this has been highly educational. (I'm new) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of * Sent: Wednesday, October 22, 2014 12:57 PM To: nanog at nanog.org Subject: Re: Linux: concerns over systemd adoption and Debian's decision to switch On 10/21/2014 05:20 PM, Jimmy Hess wrote: > The all-in-one approach of systemd might have a place on some > specialized desktop distros, but outside that niche its' IMO a > terrible idea. > > The proper fix is probably a go back to Upstart or SysVInit and > rewrite systemd, so all the pieces are separated and exist as a > higher layer on top of init. That is how systemd works, there are many parts and "systemd" is the sum of all those parts. It has a PID1 that replaces sysvinit/upstart, but afaik it doesn't do a whole lot extra. I don't use systemd, and I don't know a lot about it, but it seems lots of people don't get that it's not all lumped in PID1, there are a lot of processes that do different things that are mostly tightly held together (I think only udev and a couple other things still work without the rest of systemd.) Then again, the systemd people do spread FUD about sysvinit as well, Poettering's own blog for example even misleads on how systemd and sysvinit work http://0pointer.de/blog/projects/why.html A lot of things in the comparison chart have sysvinit listed as "no", when it's obviously not init's job directly, but a subprocess/script, except it lists "yes" for systemd on some, where systemd still passes it off to a subprocess! (They really are taking advantage of the PID1 and the entire bundle of software both being named "systemd" I guess.) [Insert obligatory "No I don't think sysvinit is perfect, but..." here] ps. What's with all the fear/hate of shell scripts? I realize the init scripts on most Linux distros are messy (200 LOC just to start sshd? Come on debian.) but the solution isn't to run away from them; rewrite scripts to have saner logic and not do a dozen redundant/unnecessary checks. From mpoublon at secantnet.net Thu Oct 23 18:27:39 2014 From: mpoublon at secantnet.net (Mike Poublon) Date: Thu, 23 Oct 2014 14:27:39 -0400 Subject: Dual BGP Sessions to Comcast Message-ID: <5449489B.5070204@secantnet.net> Anyone here have experience with running redundant BGP routers on a Comcast fiber Internet link? We are getting push back from the sales and front-line implementation groups while setting up a new BGP uplink to them. I have several full-feed Internet uplinks with various other ISP's running on a redundant pair of BGP routers. Shy of a few sanity checking questions during setup, no one has had any issues with having more than one BGP session active on a link. Thanks, -Mike From emirsosa at gmail.com Fri Oct 24 16:05:08 2014 From: emirsosa at gmail.com (Emir Sosa) Date: Fri, 24 Oct 2014 10:05:08 -0600 Subject: 4.2.2.2 4.2.2.21 High Packet Loss Message-ID: Any one else experiencing high packet loss*; *​Any word out there what's happening?​ *​Regards,Emir Sosaemirsosa at gmail.com ​* From rafael at gav.ufsc.br Sat Oct 25 02:03:34 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 24 Oct 2014 21:03:34 -0500 Subject: 4.2.2.2 4.2.2.21 High Packet Loss In-Reply-To: References: Message-ID: Those addresses are anycasted, so you would have to do a bit of research and figure out what part of their network is having any packet loss. Here is an alternative: http://www.opennicproject.org/ On Fri, Oct 24, 2014 at 11:05 AM, Emir Sosa wrote: > Any one else experiencing high packet loss*; *​Any word out there what's > happening?​ > > > > > > *​Regards,Emir Sosaemirsosa at gmail.com ​* > From josh at imaginenetworksllc.com Sat Oct 25 02:08:26 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 24 Oct 2014 22:08:26 -0400 Subject: 4.2.2.2 4.2.2.21 High Packet Loss In-Reply-To: References: Message-ID: Not really. From roughly 11:40 to 12:45 (Eastern) today there was some problem, but that's all I have. http://imgur.com/X6s58cz http://imgur.com/XGLe5Lm Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Oct 24, 2014 at 12:05 PM, Emir Sosa wrote: > Any one else experiencing high packet loss*; *​Any word out there what's > happening?​ > > > > > > *​Regards,Emir Sosaemirsosa at gmail.com ​* > From drc at virtualized.org Sat Oct 25 02:34:19 2014 From: drc at virtualized.org (David Conrad) Date: Fri, 24 Oct 2014 19:34:19 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21578.42220.902698.749301@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> Message-ID: <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> Barry, On Oct 24, 2014, at 12:13 PM, Barry Shein wrote: > I believe this never-ending quest for more reliable domain > registration data is being driven by intellectual property lawyers to > lower the cost of serving those they see as infringers either by > domain or web site content. I would agree that the intellectual property folks have interests in this area, however having sat through sessions on various illegal activities facilitated by domain names (e.g., trade in endangered species, child porn, illegal pharmacies, etc) as well as having been to anti-abuse meetings (e.g., MAAWG, APWG, RIPE abuse-wt, etc), I am fairly confident there are far more people interested in accurate registration data than merely intellectual property lawyers. Heck, I heard even some network operators would like to have accurate registration databases and I don't think many of those folks are intellectual property lawyers. > FWIW, my suggestion was to put the WHOIS data into the DNS (a new RR > perhaps) under the control of whoever manages that DNS record and if > someone needs more correct information then perhaps the registrars > could provide it (perhaps for a fee) from the sales slips (so to > speak.) You're too late: I believe there is a t-shirt that has the slogan "F* that, let's just put it in the DNS"... :) > It's just a sales record, not sure why some are trying to move heaven > and earth to idealize the information and access to it. I disagree. Perhaps my age is showing, but I believe the whole point of the registration database is to provide contact information to allow someone to contact the registrant for whatever reason, e.g., "hey, stop that!". > P.S. And of course the new WHOIS proposal involves creating classes of > access to go along with improved correctness. That is one part of the outcome of ICANN's ongoing effort to try to fix the multiple decade long nightmare that is Whois, yes. > So only bona-fide > lawyers with paid-up bar dues will be able to get at the info because, > you know, lawyers, esq. I'm not sure such a wild mischaracterization of the _166 page_ proposal for "A Next Generation Registration Directory Service" is actually helpful. The whole question of registration data is extremely complicated with a vast array of mutually contradictory requirements. As I understand it, the tiered access proposal was largely driven by the requirement to deal with the differing privacy requirements/laws/customs/etc. across the planet (e.g., the EU data privacy directives). As with anything that suggests non-trivial change, there is much that is controversial in the proposal, however I suspect it would be more useful if the controversy was based in actual reality instead of snark. For anyone actually interested, the actual proposal is at https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf (and to be clear, it is a proposal -- people are currently discussing what to do with it) Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rsk at gsp.org Sat Oct 25 12:00:14 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 25 Oct 2014 08:00:14 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21578.42220.902698.749301@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> Message-ID: <20141025120014.GB30231@gsp.org> On Fri, Oct 24, 2014 at 03:13:48PM -0400, Barry Shein wrote: > Though I've no doubt someone out there imagines improving the quality > of the database would help with spam I tend to doubt it. It might. So would removing the farce of 'private' domain registration. What would also help is removing the antiquated and byzantine boilerplate adhesions that result when one queries WHOIS data. And finally, what would help is dumping daily snapshots of all WHOIS data so that it's possible to just grab the entire thing in one compressed (text? XML?) file with a single rsync/wget -- with the minor caveat that such snapshots will always lag behind actual data. (Some folks will claim that this will result in increased spam to domain owners. This is false. First, the spammers already have all those addresses and are busy selling them to each other and using them when they see fit. Second, domain registrations are not a particularly rich source of addresses, as the subset of email addresses which are mentioned in them is small compared to the set of all email addresses.) ---rsk From danny at tcb.net Sat Oct 25 12:38:49 2014 From: danny at tcb.net (Danny McPherson) Date: Sat, 25 Oct 2014 06:38:49 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: <2d985af31ab9cf2390fc99ea7d1c3e85@tcb.net> On 2014-10-24 15:24, Christopher Morrow wrote: > it seems to me that there are a couple simple issues with IRR data > (historically): > 1) no authority for it (really, at least in the ARIN region) > 2) no common practice of keeping it updated > 3) proxy-registration issues (probably part of cleanup and > authority issues) > 4) lack of widespread use due to the above issues. I think that's a subset of the issues. Those and others are captured here: Ironically, many of the issues that lead to decay in IRR use have been resolved, while others exist in RPKI, even. Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm all for low-hanging fruit. > I was/am hopeful that providing some path from IANA (eventually) on > down through RIR to LIR to end-user for 'authority to use' ip > resources would help in letting people use the IRR data cleansed of > insanity by the data from this path, and then into routers for route > filters. And datapath filters for inter-domain anti-spoofing, perhaps, as it's largely the same policy (I know there are corner cases people that don't want to do this point out). > The RPKI system looks like the path in question, to me. I know you're an RPKI fan, I'm at peace with that :-) However, unless you can fortify the systems that RPKI (or any other resource certification infrastructure) would inform, operators have little incentive to use it as all the systems that are already deployed and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have to be used and managed and operated. RPKI adds considerable complexity, costs, scaling challenges, new external dependencies, etc.. I actually think it'd have been a challenge to design something _more complicated than RPKI to address the problem space, but that's just me. -danny From sandy at tislabs.com Sat Oct 25 12:57:36 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Sat, 25 Oct 2014 08:57:36 -0400 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: <721E6DA8-96F2-41C1-B626-365E519E6049@tislabs.com> Other RIR based RIRs have the same ability to protect prefixes in their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much as RIPE is.) Even RIPE is not secure for prefixes outside their region. (There's one maintainer that anyone can use to register anything for resources outside the region - password publicly available, etc.) Non-RIR based IRRs do not have the ability to tie the register-er to authority for the resource, so they have no base on which to build the RIPE sort of security. --Sandy (*) (yes, I'm listed as an author, but Curtis Villamizer was far and away the principal author.) On Oct 24, 2014, at 7:20 PM, Baldur Norddahl wrote: > The RIPE IRR is secure. Why not just copy that for the other regions? > > Baldur -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From woody at pch.net Sat Oct 25 13:01:56 2014 From: woody at pch.net (Bill Woodcock) Date: Sat, 25 Oct 2014 22:01:56 +0900 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <2d985af31ab9cf2390fc99ea7d1c3e85@tcb.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <2d985af31ab9cf2390fc99ea7d1c3e85@tcb.net> Message-ID: <629CD82B-10EF-418F-9093-40BD1701B373@pch.net> On Oct 25, 2014, at 9:38 PM, Danny McPherson wrote: > On 2014-10-24 15:24, Christopher Morrow wrote: > >> it seems to me that there are a couple simple issues with IRR data >> (historically): >> 1) no authority for it (really, at least in the ARIN region) >> 2) no common practice of keeping it updated >> 3) proxy-registration issues (probably part of cleanup and authority issues) >> 4) lack of widespread use due to the above issues. > > I think that's a subset of the issues. Those and others are captured here: > > > > Ironically, many of the issues that lead to decay in IRR use have been resolved, while others exist in RPKI, even. > > Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm all for low-hanging fruit. > >> I was/am hopeful that providing some path from IANA (eventually) on >> down through RIR to LIR to end-user for 'authority to use' ip >> resources would help in letting people use the IRR data cleansed of >> insanity by the data from this path, and then into routers for route >> filters. > > And datapath filters for inter-domain anti-spoofing, perhaps, as it's largely the same policy (I know there are corner cases people that don't want to do this point out). > >> The RPKI system looks like the path in question, to me. > > I know you're an RPKI fan, I'm at peace with that :-) > > However, unless you can fortify the systems that RPKI (or any other resource certification infrastructure) would inform, operators have little incentive to use it as all the systems that are already deployed and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have to be used and managed and operated. RPKI adds considerable complexity, costs, scaling challenges, new external dependencies, etc.. I actually think it'd have been a challenge to design something _more complicated than RPKI to address the problem space, but that's just me. I had dinner with Russ and Wes during the LA ICANN meeting, and asked, in passing, whether RPKI conferred any benefits that just throwing appropriate IRR records into a signed in-addr didn’t, and they had an answer in the affirmative, but I can’t remember the details now, because I was jet-lagged and it was in the middle of a conversation about something else. Russ, Wes, anyone else with an interest, could you explain that again? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jcurran at arin.net Sat Oct 25 14:25:22 2014 From: jcurran at arin.net (John Curran) Date: Sat, 25 Oct 2014 14:25:22 +0000 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> Message-ID: <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> On Oct 23, 2014, at 4:18 PM, Danny McPherson wrote: > > On 2014-10-23 12:33, Christopher Morrow wrote: > >> Sounds like you want to see the rirs make sure they get rpki work >> dine and widely available with the least encumbrances on the network >> operator community as possible. > > Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. > > I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. Just for avoidance of any doubt - The ARIN Board of Trustees has consistently directed that ARIN work on technical capabilities that the community clearly expresses some level of interest in, i.e. there is no standing directive that particular technology solutions must be (or must not be) deployed. We have had very specific requests for supporting RPKI, so we've done the necessary work for hosted and delegated certificate authority (CA) services. We can continue to enhance RPKI, or deploy other technical solutions, or some combination (as the community directs) With respect to IRR support, the same answer applies. If the community is clear on direction, ARIN can strengthen the current IRR offerings, phase them out and redirect folks to existing solutions, or any other direction as desired. The hardest part is getting a common view in the community on the desired approach; this leads to the strong adoption that is necessary for these types of systems to have meaningful benefit. FYI, /John John Curran President and CEO ARIN From danny at tcb.net Sat Oct 25 15:07:35 2014 From: danny at tcb.net (Danny McPherson) Date: Sat, 25 Oct 2014 09:07:35 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> Message-ID: <892e0cb07f15f4afd5074b7e1a1407c2@tcb.net> On 2014-10-25 08:25, John Curran wrote: > > With respect to IRR support, the same answer applies. If the > community > is clear on direction, ARIN can strengthen the current IRR offerings, > phase them out and redirect folks to existing solutions, or any other > direction as desired. The hardest part is getting a common view in > the > community on the desired approach; this leads to the strong adoption > that is necessary for these types of systems to have meaningful > benefit. I didn't necessarily intend to fault ARIN here, some very vocal folks have pushed ARIN (and others) pretty hard on focusing considerable resources on experimental systems (RPKI [/BGPSEC]) that may never see broad-scale adoption and use, for an array of technical, business, and geopolitical reasons. I could be wrong. As an ARIN and community member, I'd prefer to see more work on nearer term solutions and better leveraging existing systems that we're already captive to and will still need in the future (e.g., IRR hygiene work and more security rails, tool sets, training for operators, perhaps in-addr.arpa or other techniques to validate resource holders, etc..). If orthodox visions materialize that provide utility and a reasonable ROI without introducing excess risk and overhead and complexity and undue external dependencies for the folks that would be captive to those new systems, then great. I continue to believe that the only way any resource certification system is going to realize adoption is by taking this incremental approach of fortifying existing systems and supplying sufficient operational buffers, and that the easiest way to stunt deployment and adoption of RPKI is to slam it directly into the routing system and compromise current autonomy in routing operations that exists and makes the Internet resilient. Thanks for that response, John. -danny From jeff at ocjtech.us Sat Oct 25 15:12:55 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 25 Oct 2014 10:12:55 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <20141024151050.GA42095@reptiles.org> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> Message-ID: On Fri, Oct 24, 2014 at 10:10 AM, Jim Mercer wrote: > On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote: >> All those init.d scripts do about 95% the same thing, all hacked >> together in shell. Most of them are probably just slightly edited >> versions of some few paleo-scripts. > > in FreeBSD, the bulk of the rc.d scripts are basically the same format, > inhaling a standardized library of functions, populating some variables, > maybe adding a few custom functions, then jumping to "main". If all of the scripts are cut'n'paste copes of each other, wouldn't it be better to figure out a way to stop cutting and pasting? I can't count the number of times I've run into problems with my code because of that, never mind how many times it's happened in other people's code. -- Jeff Ollie From danny at tcb.net Sat Oct 25 15:23:45 2014 From: danny at tcb.net (Danny McPherson) Date: Sat, 25 Oct 2014 09:23:45 -0600 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <721E6DA8-96F2-41C1-B626-365E519E6049@tislabs.com> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <721E6DA8-96F2-41C1-B626-365E519E6049@tislabs.com> Message-ID: <018913705624542293da065f63cbe916@tcb.net> On 2014-10-25 06:57, Sandra Murphy wrote: > Other RIR based RIRs have the same ability to protect prefixes in > their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC > is doing pretty much as RIPE is.) > > Even RIPE is not secure for prefixes outside their region. (There's > one maintainer that anyone can use to register anything for resources > outside the region - password publicly available, etc.) > > Non-RIR based IRRs do not have the ability to tie the register-er to > authority for the resource, so they have no base on which to build > the > RIPE sort of security. Those are fair points Sandy, I agree they need to be resolved. It's just that RPKI feels like a _really heavy solution to _that problem. That said, if that problem were solved nearly all of what I care about with regard to routing security (and inter-domain anti-spoofing) could be addressed. -danny From list at satchell.net Sat Oct 25 17:22:44 2014 From: list at satchell.net (Stephen Satchell) Date: Sat, 25 Oct 2014 10:22:44 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> Message-ID: <544BDC64.1050600@satchell.net> On 10/25/2014 08:12 AM, Jeffrey Ollie wrote: > If all of the scripts are cut'n'paste copes of each other, wouldn't it > be better to figure out a way to stop cutting and pasting? I can't > count the number of times I've run into problems with my code because > of that, never mind how many times it's happened in other people's > code. I suggest that the corruption and rot was introduced when we left /etc/inittab as the sole way to run permanent daemons. We had telinit(8) already to change run levels, so expanding on telinit would have been more sensible -- telinit itself to change temporarily things temporarily (start, stop, restart), and something that modified the inittab (editor? script? GUI?) to make changes that last across boots. The first change would be to expand the daemon identifier from two characters to proper labels...but I digress. The whole rc script thing strikes me as an interim solution that required a minimum of code changes (graduate student project?) that went viral. Bad as it was, it worked. Duct tape and bailing wire.... Why did we have copy-and-paste for so long? The answer is in the form of another question: who was willing to take the time to re-factor the Sys-V way of doing things? Was "re-factor" even in the vocabulary in those days? Systemd is not a re-factoring. It's a from-scratch do-over. What it does that is good is that it provides dependency capability not available in the original inittab. It makes dependency resolution named-based (named semaphores) instead of number-based, which is what the Sys-V method used. The result is far more parallelism in system start-up than afforded by ethier of the previous methods. (I can't speak to Upstart -- I've never really understood it, or how to go from SysV to Upstart. I even filed a bug on this last point against Upstart, and saw not even "you stupid ****". Will it die?) Much of the heartburn I've been observing isn't about core systemd itself, or the goals of systemd itself, but about the culture that had grown around this replacement for the gaggle of shell scripts and the one-line-per-daemon table. Like a gun, the weapon doesn't kill people; it's the operator behind the trigger who is aiming the business end in bad directions. Much of the belly-aching has been about ripple effects that are tangential to systemd itself -- it's unfortunate that these tangents are tied to systemd, it's been said time and time again "you don't like it, you can do something about it." It means you can't use the entire package "out of the box" without changing more than a set of configuration files. My particular bone is NTP substitution -- I'd like to use my cesium clock on my Stratum 1 time server without having to spend an afternoon trying to hork everything together. I'd like for my Stratum II time server to work "out of the box" with the time servers *I* select, using the University of Delaware software. Oh, and I hate binary logs. Period. If you can't stand plain text, then try XML. At least humans have a *chance* to read it without having to make fancy reader tools. From matthew at matthew.at Sat Oct 25 17:26:34 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 25 Oct 2014 10:26:34 -0700 Subject: pay.gov and IPv6 In-Reply-To: <5327423C.7090603@matthew.at> References: <5327423C.7090603@matthew.at> Message-ID: <544BDD4A.10103@matthew.at> On 3/17/2014 11:43 AM, Matthew Kaufman wrote: > Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov > fail when clients have IPv6 enabled. Work fine if IPv6 is off. One > more set of client computers that should be dual-stacked are now > relegated to IPv4-only until someone remembers to turn it back on for > each of them... sigh. > > Matthew Kaufman Still broken, 7 months later. And again, I was too busy trying to pay to try to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're coming from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. Matthew Kaufman From chris at aperturefiber.com Sat Oct 25 12:14:26 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Sat, 25 Oct 2014 07:14:26 -0500 Subject: NOC Calendar In-Reply-To: <2679E0B4-F9B0-4825-83F3-65542B859D16@puck.nether.net> References: <2679E0B4-F9B0-4825-83F3-65542B859D16@puck.nether.net> Message-ID: The readability of this would depended entirely on your ticket volume. What we have run into is that once you get to a point where you have more than 10-15 events per day that you are tracking, then the large screen display becomes pretty useless if you want to show them all. I attached a weeks worth of display from our ticketing system calendar for reference, and this is only the maintenance tickets displayed in this view. You would need to aggregate them to a simple number happening that day to show more than a week at a time if you are a high volume shop. > On Oct 24, 2014, at 12:31 PM, Jared Mauch > wrote: > > >> On Oct 24, 2014, at 10:38 AM, chris > wrote: >> >> I was looking into something like this a while back and one thing that >> didnt seem to exist but I thought would be cool is if you could have a x86 >> box or appliance that could take video output of lets say a couple virtual >> machines and encode it into a standard TV signal so your average TV with a >> builtin tuner and have each VM's display encoded into a different TV >> channel. This way you could throw up TV's everywhere and easily change >> whats displayed at any time without having to have devices plugged into >> every TV. >> >> If this already exists or someone has built anything like this I would love >> to hear about it. > > > We have large screens in our NOC but these are mostly not used as the NOC operators have the same displays on their multiple monitors at desk. This all depends on what ones use case is and the size/scale which is feasible in your space. > > Having a proper procedure (I think we use WebcalNG or something similar) which emails out reminders of each bit of scheduled work, emergency or not to remind the people of what is occurring is seen as easier. There is also a “status page” where well known ongoing issues (e.g.: cable cuts) can be posted. This is on the big screens, so people coming on-shift can see them as they sit down. > > Hope this helps, > > - Jared From hslabbert at stargate.ca Sat Oct 25 19:50:58 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Sat, 25 Oct 2014 19:50:58 +0000 Subject: pay.gov and IPv6 In-Reply-To: <544BDD4A.10103@matthew.at> References: <5327423C.7090603@matthew.at>,<544BDD4A.10103@matthew.at> Message-ID: Why not just use a browser plugin that allow you to disable v6 selectively on a per site/domain basis? Most of them just display v4/v6 information, but 4or6 allows you to quickly set a domain/site as v4 only. Ref https://addons.mozilla.org/en-US/firefox/addon/4or6/?src=search -- Hugo On Oct 25, 2014, at 10:26, "Matthew Kaufman" > wrote: On 3/17/2014 11:43 AM, Matthew Kaufman wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman Still broken, 7 months later. And again, I was too busy trying to pay to try to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're coming from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. Matthew Kaufman From marka at isc.org Sat Oct 25 13:23:03 2014 From: marka at isc.org (Mark Andrews) Date: Sun, 26 Oct 2014 00:23:03 +1100 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: Your message of "Fri, 24 Oct 2014 19:34:19 -0700." <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> Message-ID: <20141025132303.ABE592280829@rock.dv.isc.org> In message <5526169E-D263-4132-A809-0B0A6FCE842F at virtualized.org>, David Conrad writes: > Barry, > > On Oct 24, 2014, at 12:13 PM, Barry Shein wrote: > > I believe this never-ending quest for more reliable domain > > registration data is being driven by intellectual property lawyers to > > lower the cost of serving those they see as infringers either by > > domain or web site content. > > I would agree that the intellectual property folks have interests in this > area, however having sat through sessions on various illegal activities > facilitated by domain names (e.g., trade in endangered species, child > porn, illegal pharmacies, etc) as well as having been to anti-abuse > meetings (e.g., MAAWG, APWG, RIPE abuse-wt, etc), I am fairly confident > there are far more people interested in accurate registration data than > merely intellectual property lawyers. > > Heck, I heard even some network operators would like to have accurate > registration databases and I don't think many of those folks are > intellectual property lawyers. > > > FWIW, my suggestion was to put the WHOIS data into the DNS (a new RR > > perhaps) under the control of whoever manages that DNS record and if > > someone needs more correct information then perhaps the registrars > > could provide it (perhaps for a fee) from the sales slips (so to > > speak.) > > You're too late: I believe there is a t-shirt that has the slogan "F* > that, let's just put it in the DNS"... :) > > > It's just a sales record, not sure why some are trying to move heaven > > and earth to idealize the information and access to it. > > I disagree. Perhaps my age is showing, but I believe the whole point of > the registration database is to provide contact information to allow > someone to contact the registrant for whatever reason, e.g., "hey, stop > that!". Personally I would like to be able to contact the zone owners so I can report problems with their servers. The amount of broken servers and firewalls is enourmous and it is causing operational problems. It is also fixable if you can contact the zone's administrators. http://users.isc.org/~marka/ts.html > > P.S. And of course the new WHOIS proposal involves creating classes of > > access to go along with improved correctness. > > That is one part of the outcome of ICANN's ongoing effort to try to fix > the multiple decade long nightmare that is Whois, yes. > > > So only bona-fide > > lawyers with paid-up bar dues will be able to get at the info because, > > you know, lawyers, esq. > > I'm not sure such a wild mischaracterization of the _166 page_ proposal > for "A Next Generation Registration Directory Service" is actually > helpful. The whole question of registration data is extremely complicated > with a vast array of mutually contradictory requirements. As I understand > it, the tiered access proposal was largely driven by the requirement to > deal with the differing privacy requirements/laws/customs/etc. across the > planet (e.g., the EU data privacy directives). As with anything that > suggests non-trivial change, there is much that is controversial in the > proposal, however I suspect it would be more useful if the controversy > was based in actual reality instead of snark. > > For anyone actually interested, the actual proposal is at > > https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf > > (and to be clear, it is a proposal -- people are currently discussing > what to do with it) > > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpetach at netflight.com Sat Oct 25 20:55:43 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 25 Oct 2014 13:55:43 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <544BDC64.1050600@satchell.net> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell wrote: > ... > Oh, and I hate binary logs. Period. If you can't stand plain text, > then try XML. At least humans have a *chance* to read it without having > to make fancy reader tools. > > Completely agree on this point--but I fail to see why it has to be one or the other? Why can't systemd have a --text flag to tell it to output in ascii text mode for those of us who prefer it that way? The appeal to Unix versus Windows/MacOS for me was that Unix variants believed in choice and flexibility; I find it odd to see that idea falling out of fashion now. It would seem like the systemd developers could reduce a lot of resistance simply by adding the option to emit output as text logs instead of binary logs for us Crusty Old Farts(tm). Matt From petebaldridge at gmail.com Sat Oct 25 21:41:55 2014 From: petebaldridge at gmail.com (Peter Baldridge) Date: Sat, 25 Oct 2014 14:41:55 -0700 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach wrote: > Why can't systemd have a --text flag to > tell it to output in ascii text mode for those > of us who prefer it that way? It does. --no-pager -- Pete From mpalmer at hezmatt.org Sat Oct 25 22:53:56 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 26 Oct 2014 09:53:56 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: <20141025225356.GP16429@hezmatt.org> On Sat, Oct 25, 2014 at 01:55:43PM -0700, Matthew Petach wrote: > On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell > wrote: > > Oh, and I hate binary logs. Period. If you can't stand plain text, > > then try XML. At least humans have a *chance* to read it without having > > to make fancy reader tools. > > Completely agree on this point--but I fail > to see why it has to be one or the other? > Why can't systemd have a --text flag to > tell it to output in ascii text mode for those > of us who prefer it that way? Because Lennart knows better than you. - Matt -- I remember going to my first tutorial in room 404. I was most upset when I found it. From mpalmer at hezmatt.org Sat Oct 25 22:55:06 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 26 Oct 2014 09:55:06 +1100 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: <20141025225506.GQ16429@hezmatt.org> On Sat, Oct 25, 2014 at 02:41:55PM -0700, Peter Baldridge wrote: > On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach wrote: > > Why can't systemd have a --text flag to > > tell it to output in ascii text mode for those > > of us who prefer it that way? ^ This | is not what that | does v > It does. > > --no-pager Unless I'm grossly misreading the manpages that Google things are relevant. - Matt -- Just because we work at a University doesn't mean we're surrounded by smart people. -- Brian Kantor, in the monastery From mysidia at gmail.com Sat Oct 25 22:56:52 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 Oct 2014 17:56:52 -0500 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: <544BDC64.1050600@satchell.net> References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: On Sat, Oct 25, 2014 at 12:22 PM, Stephen Satchell wrote: > The whole rc script thing strikes me as an interim solution that > required a minimum of code changes (graduate student project?) that went > viral. Bad as it was, it worked. Duct tape and bailing wire.... [snip] > Systemd is not a re-factoring. It's a from-scratch do-over. What it > does that is good is that it provides dependency capability not > available in the original inittab. It makes dependency resolution [snip] The trouble is not that systemd is a re-factoring or that it is a do-over. The problem is that the scope of the systemd project is way too large and is ever-expanding! The next thing you know, SystemD will add package management, ISO building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat, Etc to even exist. In the extreme case, at that point, we can rename GNU/Linux to GNU/SystemD, because hey, the Linux kernel is really just a little wrapper around the hardware to support the SystemD userland. The introduction of dependency support is solving issues with SysV init that are problems; I will give you that, but copy and paste init scripts and sequence-based dependencies are largely an aesthetic issue. SysV Init also has the advantage of more deterministic system startup behavior. What do you think happens when you have SystemD, but one of the critical packages has a service dependency incorrectly defined? If the scope of SystemD were appropriately constrained, it would not be also trying to replace the standard SYSLOG facilities with a program-specific logging format for everything. I'm not saying that Syslog is great; perhaps there should be new binary logging formats, or Libc built-in logging to a RDBMs, Redis database, or ElasticSearch cluster, but a distribution's choice of INIT program should not be forcing a choice on you in itself. Also.... since there are NTP daemons, DHCP, etc, all shipping with SystemD, chances are using something different will be along the path of greatest resistance. If history will be any guide; having all these extra services under the same package init, will likely mean that the maintenance will leave much to be desired ---- and you will be forced to upgrade other things and probably a reboot just to get a bug fix or security patch for your NTP client daemon. It doesn't really matter if they are not all running as PID #1. The problem is really that these services have been lumped into the scope of the same project. Proper integration into a software system does not mean expanding your scope duplicating other programs' functionality into your program, while introducing your own quirks. -- -JH From randy at psg.com Sun Oct 26 00:00:37 2014 From: randy at psg.com (Randy Bush) Date: Sun, 26 Oct 2014 09:00:37 +0900 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> Message-ID: you just happen to have the view from a third world country look at. http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5 or http://certification-stats.ripe.net/?type=roa-v4 randy From cb.list6 at gmail.com Sun Oct 26 01:57:30 2014 From: cb.list6 at gmail.com (Ca By) Date: Sat, 25 Oct 2014 18:57:30 -0700 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> Message-ID: On Sat, Oct 25, 2014 at 5:00 PM, Randy Bush wrote: > you just happen to have the view from a third world country > look at. > http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5 > or > http://certification-stats.ripe.net/?type=roa-v4 > > randy > I agree with Randy. RPKI is achievable today. Signing routes is a trivial amount of effort, there is really no excuse to not do it. Even i did it. Validation does take effort, but it is consistent with the level of effort to deploy any new router feature. CB From jcurran at arin.net Sun Oct 26 03:33:33 2014 From: jcurran at arin.net (John Curran) Date: Sun, 26 Oct 2014 03:33:33 +0000 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> Message-ID: <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net> On Oct 25, 2014, at 8:00 PM, Randy Bush wrote: > > you just happen to have the view from a third world country > look at. > http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5 > or > http://certification-stats.ripe.net/?type=roa-v4 Randy - To what extent is the ROA growth rate in the RIPE region (on page 5 of the NANOG slides) enabled by the IRR practices of that region? I do recognize that there are issues (as Wes nicely identified in Baltimore and which we'll be working on) that get in the way of RPKI deployment in the ARIN region, but those issues are not present other non-RIPE regions - yet the number actual ROA's issued still appears to be rather low... Thoughts? /John John Curran President and CEO ARIN From randy at psg.com Sun Oct 26 10:45:52 2014 From: randy at psg.com (Randy Bush) Date: Sun, 26 Oct 2014 19:45:52 +0900 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net> References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net> Message-ID: john > To what extent is the ROA growth rate in the RIPE region (on page 5 of > the NANOG slides) enabled by the IRR practices of that region? check out slide 3, lacnic has a 20% adoption rate. both ripe and lacnic have put energy into their own systems, educating users, ... ripe's curve would not seem to show correlation with recent liberalization of policy, but i doubt it is wise to twy to squeeze cause out of curves. > I do recognize that there are issues (as Wes nicely identified in > Baltimore and which we'll be working on) that get in the way of RPKI > deployment in the ARIN region, but those issues are not present other > non-RIPE regions - yet the number actual ROA's issued still appears to > be rather low... 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. slide 5 "It’s What Happens When You Let Lawyers and Wannabe Regulators Run the Internet" i really loved the arin ac guy i met in baltimore who did not think having arin meet at nanog was good because those operators just did not get how to regulate the internet. you've been captured by the tea party. randy From jcurran at arin.net Sun Oct 26 11:40:59 2014 From: jcurran at arin.net (John Curran) Date: Sun, 26 Oct 2014 11:40:59 +0000 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net>, Message-ID: On Oct 26, 2014, at 6:46 AM, Randy Bush wrote: > > 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is > damned sad)? over 2,000 in ripe and over 8%? how does that compare to > ipv6? > > arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case.... You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN From dburk at burkov.aha.ru Sun Oct 26 13:45:09 2014 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 26 Oct 2014 16:45:09 +0300 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net>, Message-ID: <74DC92FE-27F9-49B4-9F64-BB1CF21BF748@burkov.aha.ru> it's just a consequence that our initial idea was just about to protect allocations of our members - not about secure routing at all On 26 Oct 2014, at 14:40, John Curran wrote: > On Oct 26, 2014, at 6:46 AM, Randy Bush wrote: >> >> 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is >> damned sad)? over 2,000 in ripe and over 8%? how does that compare to >> ipv6? >> >> arin, 388 and 0.7%, a joke. > > LACNIC numbers (as a percent) are quite good, but my question > was why only RIPE has the very impressive total count of ROAs. > You can clearly point to ARIN's legal treatment of the risks involved, > but that is not applicable in the APNIC case.... > > You don't feel there's any correlation between RIPE's IRR approach > and their RPKI success? > > /John > > John Curran > President and CEO > ARIN From dburk at burkov.aha.ru Sun Oct 26 13:54:31 2014 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 26 Oct 2014 16:54:31 +0300 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net>, Message-ID: John - it is not about RPK I - our initial goal was to deploy some kind of certification to resources allocated to our members Dmitry If we use for it some SIDR developments - may be - it is a mistake or misentrepration - but what's true that we never thougy On 26 Oct 2014, at 14:40, John Curran wrote: > On Oct 26, 2014, at 6:46 AM, Randy Bush wrote: >> >> 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is >> damned sad)? over 2,000 in ripe and over 8%? how does that compare to >> ipv6? >> >> arin, 388 and 0.7%, a joke. > > LACNIC numbers (as a percent) are quite good, but my question > was why only RIPE has the very impressive total count of ROAs. > You can clearly point to ARIN's legal treatment of the risks involved, > but that is not applicable in the APNIC case.... > > You don't feel there's any correlation between RIPE's IRR approach > and their RPKI success? > > /John > > John Curran > President and CEO > ARIN From tlyons at ivenue.com Sun Oct 26 14:13:36 2014 From: tlyons at ivenue.com (Todd Lyons) Date: Sun, 26 Oct 2014 07:13:36 -0700 Subject: pay.gov and IPv6 In-Reply-To: <544BDD4A.10103@matthew.at> References: <5327423C.7090603@matthew.at> <544BDD4A.10103@matthew.at> Message-ID: On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman wrote: >> >> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail >> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of > Still broken, 7 months later. And again, I was too busy trying to pay to try > to pull a full set of logs. But if you do something on the FCC site that > requires payment, the redirection flow dies halfway through if you're coming > from IPv6 and works fine if you turn it off... so yet another computer in > the house has IPv6 disabled until manually turned back on. FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used the 4or6 plugin to temporarily disable ipv6 and both sites loaded straight away. eftps.gov and pay.gov appear to be managed separately since both their ipv4 and ipv6 netblocks are not in the same netblocks, and my path to them is not the same: eftps.gov has IPv6 address 2620:10f:400e:a::13 mtr to eftps.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 16 0.9 0.9 0.9 1.6 0.2 2. gw-701.chi-03.us.sixxs.net 0.0% 16 71.6 72.4 68.6 78.3 2.4 3. uschi03.sixxs.net 0.0% 16 70.2 71.8 69.2 78.8 2.4 4. 2620:0:6b0:a::1 0.0% 15 67.3 73.3 67.3 79.7 3.2 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 15 73.6 75.4 70.1 85.4 4.9 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 15 73.5 79.7 72.9 90.4 5.7 7. 2600:805:41f::5 0.0% 15 104.4 81.9 74.2 104.4 9.0 8. 2600:806::12 0.0% 15 105.2 104.0 100.6 109.8 2.9 9. 2600:806:12f::2e 0.0% 15 134.5 135.7 131.4 147.4 4.1 10. 2620:10f:400e:1::4004 0.0% 15 161.5 145.9 131.5 163.8 9.9 11. ??? pay.gov has IPv6 address 2605:3100:fffd:100::15 mtr to pay.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 11 0.9 0.9 0.7 1.1 0.1 2. gw-701.chi-03.us.sixxs.net 0.0% 11 70.8 70.9 67.0 74.4 2.2 3. uschi03.sixxs.net 0.0% 11 73.7 73.7 69.8 90.1 5.6 4. 2620:0:6b0:a::1 0.0% 11 70.6 73.7 70.4 86.2 5.0 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 11 72.4 75.6 71.5 82.6 3.2 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 11 76.1 79.3 74.7 87.9 4.0 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0% 11 99.1 100.1 96.4 106.2 2.7 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net 0.0% 11 98.2 102.0 98.2 111.0 4.4 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0% 11 99.5 100.5 96.2 105.5 2.5 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0% 11 96.4 98.8 96.4 105.1 2.6 11. 2600:4:2000:4::9 0.0% 11 100.2 102.0 99.0 107.0 2.7 12. ??? I was hoping an eftps.gov or pay.gov employee was casting an eye this way, but it doesn't look like anybody from there is subscribed to NANOG. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine From paigeadele at gmail.com Sun Oct 26 14:17:08 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Sun, 26 Oct 2014 14:17:08 +0000 Subject: 4.2.2.2 4.2.2.21 High Packet Loss In-Reply-To: References: Message-ID: <544D0264.3070501@gmail.com> On 10/25/14 02:03, Rafael Possamai wrote: > Those addresses are anycasted, so you would have to do a bit of research > and figure out what part of their network is having any packet loss. > > Here is an alternative: http://www.opennicproject.org/ > > > > On Fri, Oct 24, 2014 at 11:05 AM, Emir Sosa wrote: > >> Any one else experiencing high packet loss*; *​Any word out there what's >> happening?​ >> >> >> >> >> >> *​Regards,Emir Sosaemirsosa at gmail.com ​* >> Are you familiar with mtr (my traceroute) try this: Konsole output erratic at laptop~ $mtr -c 10 --report 4.2.2.1 Start: Sun Oct 26 14:16:00 2014 HOST: laptop Loss% Snt Last Avg Best Wrst StDev 1.|-- 206.125.168.65 0.0% 10 235.6 240.5 235.2 281.3 14.3 2.|-- 208.79.92.65 0.0% 10 241.7 249.3 235.8 295.8 17.2 3.|-- 208.79.88.135 0.0% 10 245.1 237.2 234.7 245.1 3.1 4.|-- 4.71.143.105 0.0% 10 244.4 294.9 243.6 369.4 51.6 5.|-- 4.69.201.17 0.0% 10 245.4 245.8 244.3 248.2 0.9 6.|-- 4.69.144.73 0.0% 10 243.5 249.2 243.3 296.9 16.7 7.|-- 4.2.2.1 0.0% 10 245.4 245.3 244.3 249.3 1.4 erratic at laptop~ $ was seeing quite a bit of loss on level3 a minute ago in --ncurses. From Valdis.Kletnieks at vt.edu Sun Oct 26 18:20:05 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 26 Oct 2014 14:20:05 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: Your message of "Sat, 25 Oct 2014 17:56:52 -0500." References: <5445AD63.7090400@lugosys.com> <54493E27.4040405@pari.edu> <54495D07.3040405@satchell.net> <21577.55427.300064.883007@world.std.com> <20141024151050.GA42095@reptiles.org> <544BDC64.1050600@satchell.net> Message-ID: <20437.1414347605@turing-police.cc.vt.edu> On Sat, 25 Oct 2014 17:56:52 -0500, Jimmy Hess said: > The next thing you know, SystemD will add package management, ISO > building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat, > Etc to even exist. That's already on Lennart's to-do list, you know. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From marka at isc.org Sun Oct 26 21:16:43 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 27 Oct 2014 08:16:43 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Sun, 26 Oct 2014 07:13:36 -0700." References: <5327423C.7090603@matthew.at> <544BDD4A.10103@matthew.at> Message-ID: <20141026211643.822F3228311D@rock.dv.isc.org> In message , Todd Lyons writes: > On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman wrote: > >> > >> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail > >> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of > > Still broken, 7 months later. And again, I was too busy trying to pay to tr > y > > to pull a full set of logs. But if you do something on the FCC site that > > requires payment, the redirection flow dies halfway through if you're comin > g > > from IPv6 and works fine if you turn it off... so yet another computer in > > the house has IPv6 disabled until manually turned back on. > > FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, > and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used > the 4or6 plugin to temporarily disable ipv6 and both sites loaded > straight away. If a site is unreachable your client should switch to IPv4 unless a IPv6 literal has been used. If your client take ages to switch over report a bug to the client vendor. It should not take ages to switch between multiple server addresses. IPv4 + IPv6 is just a example of multiple server addresses. > eftps.gov and pay.gov appear to be managed separately since both their > ipv4 and ipv6 netblocks are not in the same netblocks, and my path to > them is not the same: > > eftps.gov has IPv6 address 2620:10f:400e:a::13 > mtr to eftps.gov via Sixxs: > Host Loss% Snt Last > Avg Best Wrst StDev > 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 16 0.9 > 0.9 0.9 1.6 0.2 > 2. gw-701.chi-03.us.sixxs.net 0.0% 16 71.6 > 72.4 68.6 78.3 2.4 > 3. uschi03.sixxs.net 0.0% 16 70.2 > 71.8 69.2 78.8 2.4 > 4. 2620:0:6b0:a::1 0.0% 15 67.3 > 73.3 67.3 79.7 3.2 > 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 15 73.6 > 75.4 70.1 85.4 4.9 > 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 15 73.5 > 79.7 72.9 90.4 5.7 > 7. 2600:805:41f::5 0.0% 15 104.4 > 81.9 74.2 104.4 9.0 > 8. 2600:806::12 0.0% 15 105.2 > 104.0 100.6 109.8 2.9 > 9. 2600:806:12f::2e 0.0% 15 134.5 > 135.7 131.4 147.4 4.1 > 10. 2620:10f:400e:1::4004 0.0% 15 161.5 > 145.9 131.5 163.8 9.9 > 11. ??? > > pay.gov has IPv6 address 2605:3100:fffd:100::15 > mtr to pay.gov via Sixxs: > Host Loss% Snt Last > Avg Best Wrst StDev > 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 11 0.9 > 0.9 0.7 1.1 0.1 > 2. gw-701.chi-03.us.sixxs.net 0.0% 11 70.8 > 70.9 67.0 74.4 2.2 > 3. uschi03.sixxs.net 0.0% 11 73.7 > 73.7 69.8 90.1 5.6 > 4. 2620:0:6b0:a::1 0.0% 11 70.6 > 73.7 70.4 86.2 5.0 > 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 11 72.4 > 75.6 71.5 82.6 3.2 > 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 11 76.1 > 79.3 74.7 87.9 4.0 > 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0% 11 99.1 > 100.1 96.4 106.2 2.7 > 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net 0.0% 11 98.2 > 102.0 98.2 111.0 4.4 > 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0% 11 99.5 > 100.5 96.2 105.5 2.5 > 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0% 11 96.4 > 98.8 96.4 105.1 2.6 > 11. 2600:4:2000:4::9 0.0% 11 100.2 > 102.0 99.0 107.0 2.7 > 12. ??? > > I was hoping an eftps.gov or pay.gov employee was casting an eye this > way, but it doesn't look like anybody from there is subscribed to > NANOG. > > ...Todd > -- > The total budget at all receivers for solving senders' problems is $0. > If you want them to accept your mail and manage it the way you want, > send it the way the spec says to. --John Levine -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marine64 at gmail.com Sun Oct 26 21:32:18 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 26 Oct 2014 17:32:18 -0400 Subject: pay.gov and IPv6 In-Reply-To: <20141026211643.822F3228311D@rock.dv.isc.org> References: <5327423C.7090603@matthew.at> <544BDD4A.10103@matthew.at> <20141026211643.822F3228311D@rock.dv.isc.org> Message-ID: Have you tried emailing the server admin at pay.gov.clev at clev.frb.org? On Sun, Oct 26, 2014 at 5:16 PM, Mark Andrews wrote: > > In message vL3nnQ at mail.gmail.com> > , Todd Lyons writes: > > On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman > wrote: > > >> > > >> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov > fail > > >> when clients have IPv6 enabled. Work fine if IPv6 is off. One more > set of > > > Still broken, 7 months later. And again, I was too busy trying to pay > to tr > > y > > > to pull a full set of logs. But if you do something on the FCC site > that > > > requires payment, the redirection flow dies halfway through if you're > comin > > g > > > from IPv6 and works fine if you turn it off... so yet another computer > in > > > the house has IPv6 disabled until manually turned back on. > > > > FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, > > and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used > > the 4or6 plugin to temporarily disable ipv6 and both sites loaded > > straight away. > > If a site is unreachable your client should switch to IPv4 unless > a IPv6 literal has been used. > > If your client take ages to switch over report a bug to the client > vendor. > > It should not take ages to switch between multiple server addresses. > IPv4 + IPv6 is just a example of multiple server addresses. > > > eftps.gov and pay.gov appear to be managed separately since both their > > ipv4 and ipv6 netblocks are not in the same netblocks, and my path to > > them is not the same: > > > > eftps.gov has IPv6 address 2620:10f:400e:a::13 > > mtr to eftps.gov via Sixxs: > > Host Loss% Snt Last > > Avg Best Wrst StDev > > 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 16 0.9 > > 0.9 0.9 1.6 0.2 > > 2. gw-701.chi-03.us.sixxs.net 0.0% 16 71.6 > > 72.4 68.6 78.3 2.4 > > 3. uschi03.sixxs.net 0.0% 16 70.2 > > 71.8 69.2 78.8 2.4 > > 4. 2620:0:6b0:a::1 0.0% 15 67.3 > > 73.3 67.3 79.7 3.2 > > 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 15 73.6 > > 75.4 70.1 85.4 4.9 > > 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 15 73.5 > > 79.7 72.9 90.4 5.7 > > 7. 2600:805:41f::5 0.0% 15 104.4 > > 81.9 74.2 104.4 9.0 > > 8. 2600:806::12 0.0% 15 105.2 > > 104.0 100.6 109.8 2.9 > > 9. 2600:806:12f::2e 0.0% 15 134.5 > > 135.7 131.4 147.4 4.1 > > 10. 2620:10f:400e:1::4004 0.0% 15 161.5 > > 145.9 131.5 163.8 9.9 > > 11. ??? > > > > pay.gov has IPv6 address 2605:3100:fffd:100::15 > > mtr to pay.gov via Sixxs: > > Host Loss% Snt Last > > Avg Best Wrst StDev > > 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 11 0.9 > > 0.9 0.7 1.1 0.1 > > 2. gw-701.chi-03.us.sixxs.net 0.0% 11 70.8 > > 70.9 67.0 74.4 2.2 > > 3. uschi03.sixxs.net 0.0% 11 73.7 > > 73.7 69.8 90.1 5.6 > > 4. 2620:0:6b0:a::1 0.0% 11 70.6 > > 73.7 70.4 86.2 5.0 > > 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 11 72.4 > > 75.6 71.5 82.6 3.2 > > 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 11 76.1 > > 79.3 74.7 87.9 4.0 > > 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0% 11 99.1 > > 100.1 96.4 106.2 2.7 > > 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net 0.0% 11 98.2 > > 102.0 98.2 111.0 4.4 > > 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0% 11 99.5 > > 100.5 96.2 105.5 2.5 > > 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0% 11 96.4 > > 98.8 96.4 105.1 2.6 > > 11. 2600:4:2000:4::9 0.0% 11 100.2 > > 102.0 99.0 107.0 2.7 > > 12. ??? > > > > I was hoping an eftps.gov or pay.gov employee was casting an eye this > > way, but it doesn't look like anybody from there is subscribed to > > NANOG. > > > > ...Todd > > -- > > The total budget at all receivers for solving senders' problems is $0. > > If you want them to accept your mail and manage it the way you want, > > send it the way the spec says to. --John Levine > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From matthew at matthew.at Mon Oct 27 01:39:44 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 26 Oct 2014 18:39:44 -0700 Subject: pay.gov and IPv6 In-Reply-To: <20141026211643.822F3228311D@rock.dv.isc.org> References: <5327423C.7090603@matthew.at> <544BDD4A.10103@matthew.at> <20141026211643.822F3228311D@rock.dv.isc.org> Message-ID: This is why I need to pull logs the next time I need to pay the FCC. There are several rounds of redirects involved from clicking the payment button on the FCC site to the final landing at pay.gov, and one of the last steps never connects if IPv6 is enabled. Matthew Kaufman (Sent from my iPhone) > On Oct 26, 2014, at 2:16 PM, Mark Andrews wrote: > > > In message > , Todd Lyons writes: >> On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman wrote: >>>> >>>> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail >>>> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of >>> Still broken, 7 months later. And again, I was too busy trying to pay to tr >> y >>> to pull a full set of logs. But if you do something on the FCC site that >>> requires payment, the redirection flow dies halfway through if you're comin >> g >>> from IPv6 and works fine if you turn it off... so yet another computer in >>> the house has IPv6 disabled until manually turned back on. >> >> FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, >> and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used >> the 4or6 plugin to temporarily disable ipv6 and both sites loaded >> straight away. > > If a site is unreachable your client should switch to IPv4 unless > a IPv6 literal has been used. > > If your client take ages to switch over report a bug to the client > vendor. > > It should not take ages to switch between multiple server addresses. > IPv4 + IPv6 is just a example of multiple server addresses. > >> eftps.gov and pay.gov appear to be managed separately since both their >> ipv4 and ipv6 netblocks are not in the same netblocks, and my path to >> them is not the same: >> >> eftps.gov has IPv6 address 2620:10f:400e:a::13 >> mtr to eftps.gov via Sixxs: >> Host Loss% Snt Last >> Avg Best Wrst StDev >> 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 16 0.9 >> 0.9 0.9 1.6 0.2 >> 2. gw-701.chi-03.us.sixxs.net 0.0% 16 71.6 >> 72.4 68.6 78.3 2.4 >> 3. uschi03.sixxs.net 0.0% 16 70.2 >> 71.8 69.2 78.8 2.4 >> 4. 2620:0:6b0:a::1 0.0% 15 67.3 >> 73.3 67.3 79.7 3.2 >> 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 15 73.6 >> 75.4 70.1 85.4 4.9 >> 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 15 73.5 >> 79.7 72.9 90.4 5.7 >> 7. 2600:805:41f::5 0.0% 15 104.4 >> 81.9 74.2 104.4 9.0 >> 8. 2600:806::12 0.0% 15 105.2 >> 104.0 100.6 109.8 2.9 >> 9. 2600:806:12f::2e 0.0% 15 134.5 >> 135.7 131.4 147.4 4.1 >> 10. 2620:10f:400e:1::4004 0.0% 15 161.5 >> 145.9 131.5 163.8 9.9 >> 11. ??? >> >> pay.gov has IPv6 address 2605:3100:fffd:100::15 >> mtr to pay.gov via Sixxs: >> Host Loss% Snt Last >> Avg Best Wrst StDev >> 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0% 11 0.9 >> 0.9 0.7 1.1 0.1 >> 2. gw-701.chi-03.us.sixxs.net 0.0% 11 70.8 >> 70.9 67.0 74.4 2.2 >> 3. uschi03.sixxs.net 0.0% 11 73.7 >> 73.7 69.8 90.1 5.6 >> 4. 2620:0:6b0:a::1 0.0% 11 70.6 >> 73.7 70.4 86.2 5.0 >> 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0% 11 72.4 >> 75.6 71.5 82.6 3.2 >> 6. ve8.fr3.ord.ipv6.llnw.net 0.0% 11 76.1 >> 79.3 74.7 87.9 4.0 >> 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0% 11 99.1 >> 100.1 96.4 106.2 2.7 >> 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net 0.0% 11 98.2 >> 102.0 98.2 111.0 4.4 >> 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0% 11 99.5 >> 100.5 96.2 105.5 2.5 >> 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0% 11 96.4 >> 98.8 96.4 105.1 2.6 >> 11. 2600:4:2000:4::9 0.0% 11 100.2 >> 102.0 99.0 107.0 2.7 >> 12. ??? >> >> I was hoping an eftps.gov or pay.gov employee was casting an eye this >> way, but it doesn't look like anybody from there is subscribed to >> NANOG. >> >> ...Todd >> -- >> The total budget at all receivers for solving senders' problems is $0. >> If you want them to accept your mail and manage it the way you want, >> send it the way the spec says to. --John Levine > -- > 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 Oct 27 02:15:48 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 26 Oct 2014 19:15:48 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21578.42220.902698.749301@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> Message-ID: <544DAAD4.6070803@nic-naa.net> David wrote: > Indeed, and I must commend Warren and Eric for caring enough to actually engage in this stuff. While many people in the NANOG/IETF/DNS Operations communities complain about the latest abomination ICANN is inflicting upon the world, there aren't a whole lot of folks from those communities who take the (non-trivial) amount of time to try to understand and address the situation. While I fully understand the rationales for not participating, the lack of strong representation from the technical community does not help in preventing abominations. The number of technically capable with multi-meeting attendance records is wicked limited, and most are silo'd off -- into SSAC or TAC or ASO or ... or attending annual co-gigs like OARC, and so, with the exception of those working for registries, rarely involved in actual policy development where it actually happens -- at the GNSO Council -- as all policy relating to generic top-level domains originates in the GNSO, via a or the (by abuse of notation) Policy Development Process (PDP). So if there is a point to a ISPCP stakeholders group (formerly the ISP Constituency), it is to have votes in the GNSO Council and so be capable of (a) originating a policy activity (a PDP), and (b) being eligible to chair the resulting working group, and (c) being eligible to vote on the recommendation(s) of the working group. Otherwise it is ornamental, a reflection of one of the several errors of judgement of the Roberts/Dyson/Touton team back when "multi-stakeholder(ism)" was being made up as an alternative to the contractor-agency binary relationship. It takes years to get things done, and things happen, even on Constituency Day, as Warren noted, so this isn't a send-one-staffer-and-expect-goodness kind of investment. The competent teams are three or more, and work years of meetings to achieve their policy ends. > I think it safe to say that much (but not all) of the warfare that goes on at ICANN meetings is between the folks interested in protecting IPR (in this context, trademarks) and folks interested in selling oodles of domain names. Generally true. Counter-examples: Sitefinder, FastFlux, ... There are other axis of evils, somewhat orthogonal to the infringement vs volume conflict of interests, but absent what I think of as "operators" (of oodles of wire or piles of cooling kit), all issues that involve name-to-resource mappings where ICANN policy, not national law, is dispositive, are and will continue to be determined by one or the other of the infringement vs volume parties. Eric From randy at psg.com Mon Oct 27 02:58:04 2014 From: randy at psg.com (Randy Bush) Date: Mon, 27 Oct 2014 11:58:04 +0900 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net> Message-ID: > LACNIC numbers (as a percent) are quite good, but my question > was why only RIPE has the very impressive total count of ROAs. < conjecture follows > of course one can never know. but i conject o the are the largest registry actively promotin registration o the ncc, particularly alex, tim, oleg, ... have put significant effort into making it very easy to register o they have a culture of cooperation and doing things well > You can clearly point to ARIN's legal treatment of the risks involved, > but that is not applicable in the APNIC case.... it is hard to register in apnic, ask folk who have tried. the most active folk are under NIRs, who are only now working on deployment. apnic is not really promoting it. > You don't feel there's any correlation between RIPE's IRR approach and > their RPKI success? that's the cooperative culture bit, actually interested in the net running well. randy From bzs at world.std.com Mon Oct 27 04:25:18 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 27 Oct 2014 00:25:18 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <544DAAD4.6070803@nic-naa.net> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <544DAAD4.6070803@nic-naa.net> Message-ID: <21581.51502.341291.859756@world.std.com> I think one missing or weak component are those who actually make this stuff work vs the pie-in-the-sky infringer/volume/policy crowd. I've sat in IPC meetings and suffice it to say there isn't much clue on that front and why should there be unless the go-fast/go-always crowd shows up? Sure it does tend to creep in as proposed policies escape and get the attention of the doers but the danger is by that time the infringer/volume crowd might be quite committed to their vision: Make PI=3.0 and full steam ahead. What's also often lacking is simply administrative and management insight but that's not particularly germaine to this group. But I did get into a minor shouting match with an IP lawyer last week in LA who just didn't understand why service providers won't drop everything we're doing to rush through their discovery needs, for free, without indemnification (or similar), or jurisdicational authority, on an as-needed basis. -- -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 jcurran at arin.net Mon Oct 27 12:06:02 2014 From: jcurran at arin.net (John Curran) Date: Mon, 27 Oct 2014 12:06:02 +0000 Subject: ARIN / RIR Pragmatism (WAS: Re: RADB) In-Reply-To: References: <1412801047.14050.YahooMailNeo@web164904.mail.bf1.yahoo.com> <1799352989.127496.1412817303510.JavaMail.zimbra@snappytelecom.net> <1412822137.3431.YahooMailNeo@web164902.mail.bf1.yahoo.com> <5bf5e66910c8acc4170b08e6190b5d6b@tcb.net> <47D76F45-55AA-4FAD-9892-FC3151B7A9AF@arin.net> <8FD5A559-AC25-41D1-8820-6F11A566AD0E@arin.net> Message-ID: <8B7A8BDD-2161-4332-82AA-98EC75B70231@arin.net> On Oct 27, 2014, at 12:58 AM, Randy Bush wrote: > >> LACNIC numbers (as a percent) are quite good, but my question >> was why only RIPE has the very impressive total count of ROAs. > > < conjecture follows > > > of course one can never know. but i conject > o the are the largest registry actively promotin registration > o the ncc, particularly alex, tim, oleg, ... have put significant > effort into making it very easy to register > o they have a culture of cooperation and doing things well Reasonable conjecture; implies that in this region we need to overcome our interesting legal situation, make things easy to use, and then do some significant promotion. >> You can clearly point to ARIN's legal treatment of the risks involved, >> but that is not applicable in the APNIC case.... > > it is hard to register in apnic, ask folk who have tried. the most > active folk are under NIRs, who are only now working on deployment. > apnic is not really promoting it. Ah, good to know (and reinforces potential ARIN issues beyond legal wrangling) >> You don't feel there's any correlation between RIPE's IRR approach and >> their RPKI success? > > that's the cooperative culture bit, actually interested in the net > running well. Presumably the NANOG community is also interested in keeping the net running well, so if ARIN can provide some reasonably usable services, that shouldn't be an issue. Thanks! /John John Curran President and CEO ARIN From jra at baylink.com Mon Oct 27 15:22:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 27 Oct 2014 11:22:05 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <22959008.620.1414423325665.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Gregory Boyce" > > On Wed, Oct 22, 2014 at 5:17 PM, Jeffrey Ollie > > wrote: > >> I think that Debian's plan to allow multiple init systems > >> (irregardless of which one is default) is a bad plan. The > >> non-default > >> ones won't get any love - at some point they'll just stop working > >> (or > >> indeed, work at all). > > > > If they break then one of two things will happen: > > > > 1) Someone will fix it. > > > > 2) No one will fix it because no one cares. If no one cares, then it > > being broken doesn't matter. > > > > Killing off choice/alternatives just in case no one cares about them > > isn't especially helpful. 3) A lot of people who do care and either cannot afford to or are technically competent to fix it are screwed. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Oct 27 15:24:13 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 27 Oct 2014 11:24:13 -0400 (EDT) Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <20141024204150.GA1267@cmadams.net> Message-ID: <28793350.624.1414423453599.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Adams" > Once upon a time, Jay Ashworth said: > > "Try to do everything *inside PID 1*" is the real problem. > > And that is not what systemd is doing; make sure you know what you are > complaining about. systemd-the-project != systemd-the-pid-1. PID 1 is > responsible for managing services/daemons, and AFAIK that's all > systemd's PID 1 does. Indeed. I was quoting (I thought) better read people than me. If that's the case, I retract about 25% of my distaste for it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Oct 27 15:35:30 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 27 Oct 2014 11:35:30 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Jeffrey Ollie" > On Wed, Oct 22, 2014 at 9:48 PM, Jimmy Hess wrote: > > On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein > > wrote: > >> And you whisk all that away with "it's not really clear to me that > >> 'reboots in seconds' is a think to be optimized"???? > > > > False dilemma. > > [ snip ] > > 10 seconds from power on to user interface for desktops, will > > meaningfully improve the user experience, but not for servers. > > It's a false dilemma only if you're thinking about traditional > physical servers. Consider: > > 1) What if you're spinning up several thousand Hadoop nodes on AWS or > GCE so that you can do some sort of "big data" operation. > > 2) What if PewDiePie just mentioned one of your products in a video > and you need to quickly scale up the number of backend servers to > handle the load. > > I'm sure that there are many other scenarios that I could devise where > a fast "server" boot time was important. I will stipulate this use case. I will counter with "you wouldn't be running a "real" distro in that case anyway; you'd be running something super trimmed down, and possibly custom built, or based on something like CoreOS, that only does one job. Well. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jim at reptiles.org Mon Oct 27 15:42:17 2014 From: jim at reptiles.org (Jim Mercer) Date: Mon, 27 Oct 2014 11:42:17 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> References: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> Message-ID: <20141027154217.GA57292@reptiles.org> after watching this discussion for a while, i have decided that i am in favour of systemd. i encourage its development, and widespread adoption. it will hasten the demise of linux in the server enviroment, which can only be a good thing. if people really want to run their servers on the *nix equivilent of Windows/XP, i say let them go ahead. every day that i have to work with linux, is another day i spend holding my nose. --jim -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From ag4ve.us at gmail.com Mon Oct 27 15:57:15 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 27 Oct 2014 11:57:15 -0400 Subject: Trying to identify hosts Message-ID: We get lots of probes from subdomains of southwestdoor.com and secureserver.net 's SOA and I'm curious who these guys are? The only web page I could find was southwestdoor redirects to http://www.arcadiacustoms.com and then to http://arcadia-custom.com/ (a hardware company is causing unwanted network traffic - not unless they're owned) Traceroute for southwestdoor.com goes through secureserver.net and they have lots of references (in dns) to themselves, jomax.net and domaincontrol.com. Can someone give me a better picture of how this all fits together on a company level - as in how do these guys make money and why are they probing our network? I understand scans from ISPs and colos, but I can't directly identify these guys as either. From jeff at ocjtech.us Mon Oct 27 16:26:20 2014 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 27 Oct 2014 11:26:20 -0500 Subject: Linux: concerns over systemd [OT] In-Reply-To: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> References: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Oct 27, 2014 at 10:35 AM, Jay Ashworth wrote: > > I will stipulate this use case. > > I will counter with "you wouldn't be running a "real" distro in that > case anyway; you'd be running something super trimmed down, and possibly > custom built, or based on something like CoreOS, that only does one job. > > Well. :-) From: https://coreos.com/using-coreos/systemd/ "CoreOS uses systemd as the core of its distributed init system, fleet. Systemd is well supported in many Linux distros, making it familiar to most engineers. Every aspect of CoreOS is deeply integrated with systemd." -- Jeff Ollie From owen at delong.com Mon Oct 27 16:27:24 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Oct 2014 09:27:24 -0700 Subject: NOC Calendar In-Reply-To: References: Message-ID: <30ACD0D6-DF8A-45F7-834B-478933A01201@delong.com> There are boxes that do that, but it’s really not a good solution… Here’s why: 1. TV signals in NTSC max out at 640x480. In ATSC, you get up to 1920x1080. Many monitors today are capable of 2560x1440 or more. 2. It’s expensive and has few advantages over a traditional KVM switch. 3. An HDMI switcher and graphic cards with HDMI output are not particularly hard to find these days. DVI->HDMI is also relatively easy if you have trouble getting HDMI out of the machine. This is a much less expensive solution. Its fairly trivial to get VM video out to HDMI if you’re willing to dedicate hardware to the task. Owen > On Oct 24, 2014, at 7:38 AM, chris wrote: > > I was looking into something like this a while back and one thing that > didnt seem to exist but I thought would be cool is if you could have a x86 > box or appliance that could take video output of lets say a couple virtual > machines and encode it into a standard TV signal so your average TV with a > builtin tuner and have each VM's display encoded into a different TV > channel. This way you could throw up TV's everywhere and easily change > whats displayed at any time without having to have devices plugged into > every TV. > > If this already exists or someone has built anything like this I would love > to hear about it. > > - chris > > On Fri, Oct 24, 2014 at 10:07 AM, James Wininger > wrote: > >> Does anyone on the list have a reference to a good "NOC" calendar? What I >> mean by that is a calendar that is view only for the NOC, but looks "good" >> on a larger LCD panel display. >> >> Ideally it would automatically rotate on a given schedule (say 6am), and >> then show only that days scheduled events, there would be no need for the >> NOC to interact with the calendar, just consume the data. >> >> Perhaps it would be color coded to show "DWDM work", vs MPLS work, or even >> "new installs". But the idea is that the NOC would have readily accessible >> "view only" at a glance. They would not have to load up outlook, go to >> calendar, select the MPLS, install etc to see what work is happening. >> >> >> -- >> Jim Wininger >> >> From jra at baylink.com Mon Oct 27 16:38:47 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 27 Oct 2014 12:38:47 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: Message-ID: <19530859.654.1414427927901.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeffrey Ollie" > On Mon, Oct 27, 2014 at 10:35 AM, Jay Ashworth > wrote: > > > > I will stipulate this use case. > > > > I will counter with "you wouldn't be running a "real" distro in that > > case anyway; you'd be running something super trimmed down, and > > possibly > > custom built, or based on something like CoreOS, that only does one > > job. > > > > Well. :-) > > From: https://coreos.com/using-coreos/systemd/ > > "CoreOS uses systemd as the core of its distributed init system, > fleet. Systemd is well supported in many Linux distros, making it > familiar to most engineers. Every aspect of CoreOS is deeply > integrated with systemd." Surprisingly, I actually knew this already. You might want to stop trying to score points, rather than actually, y'know, just advancing the conversation. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From brunner at nic-naa.net Mon Oct 27 16:57:37 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 27 Oct 2014 09:57:37 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21581.51502.341291.859756@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <544DAAD4.6070803@nic-naa.net> <21581.51502.341291.859756@world.std.com> Message-ID: <544E7981.7030705@nic-naa.net> On 10/26/14 9:25 PM, Barry Shein wrote: > I think one missing or weak component are those who actually make this > stuff work vs the pie-in-the-sky infringer/volume/policy crowd. > > I've sat in IPC meetings and suffice it to say there isn't much clue > on that front and why should there be unless the go-fast/go-always > crowd shows up? they're trademark lawyers. they'll know about pokey, but not much else, and they may not be able to articulate why infringement as a risk exists at the first and second levels, but not so much further down the tree. > Sure it does tend to creep in as proposed policies escape and get the > attention of the doers but the danger is by that time the > infringer/volume crowd might be quite committed to their vision: Make > PI=3.0 and full steam ahead. as i mentioned, policy originates in the gnso. by the time it is "available" for those not having a vote in the gnso council the policy is generally baked in, so pi is three. > What's also often lacking is simply administrative and management > insight but that's not particularly germaine to this group. icann's administration and mangement of constituencies is "light", and those playing the long game (generally those lobbyists with clients and more than 20 meetings of time-on-target) know that process, budget and agenda control is where the game is won or lost. as for getting operational clue, other than that of the registries, to where pi is defined as an integer, well, that simply revisits david's point that the ops people are broadly a no-show, and most that do show bath ritually when outside of their silos. > > But I did get into a minor shouting match with an IP lawyer last week > in LA who just didn't understand why service providers won't drop > everything we're doing to rush through their discovery needs, for > free, without indemnification (or similar), or jurisdicational > authority, on an as-needed basis. > who? i may know him or her -- i had to work with the ipc to protect tribal names -- over the objections of milton meuller and robin gross and so on who think tribes are evil trademark holders -- and shouting may not be the only means of communicating effectively. -e From ag4ve.us at gmail.com Mon Oct 27 17:21:19 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 27 Oct 2014 13:21:19 -0400 Subject: Trying to identify hosts In-Reply-To: References: Message-ID: Ok, got a few off list replies that secureserver.net is godaddy which is fine - makes sense. I just wish this would link back to them easier (some backup ns being something.godaddy.com or some SOA of an IP listed in the spf being something.godaddy.com or whatever). Thank y'all for the info. On Mon, Oct 27, 2014 at 11:57 AM, shawn wilson wrote: > We get lots of probes from subdomains of southwestdoor.com and > secureserver.net 's SOA and I'm curious who these guys are? > > The only web page I could find was southwestdoor redirects to > http://www.arcadiacustoms.com and then to http://arcadia-custom.com/ > (a hardware company is causing unwanted network traffic - not unless > they're owned) > > Traceroute for southwestdoor.com goes through secureserver.net and > they have lots of references (in dns) to themselves, jomax.net and > domaincontrol.com. > > Can someone give me a better picture of how this all fits together on > a company level - as in how do these guys make money and why are they > probing our network? I understand scans from ISPs and colos, but I > can't directly identify these guys as either. From ag4ve.us at gmail.com Mon Oct 27 17:28:22 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 27 Oct 2014 13:28:22 -0400 Subject: Trying to identify hosts In-Reply-To: References: Message-ID: Oh and along that line of trying to find the source - nothing indicates godaddy here (kinda annoying): % curl -I secureserver.net ~ swlap1 HTTP/1.1 301 Moved Permanently Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Content-Length: 145 Expires: 0 Location: http://www.secureserver.net/ Server: Microsoft-IIS/7.0 P3P: policyref="/w3c/p3p.xml", CP="COM CNT DEM FIN GOV INT NAV ONL PHY PRE PUR STA UNI IDC CAO OTI DSP COR CUR OUR IND" Date: Mon, 27 Oct 2014 16:02:33 GMT % curl -I www.secureserver.net ~ swlap1 HTTP/1.1 302 Found Cache-Control: no-cache Pragma: no-cache Content-Length: 160 Content-Type: text/html; charset=utf-8 Expires: -1 Location: http://www.secureserver.net/default404.aspx Server: Microsoft-IIS/7.0 Set-Cookie: language0=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: market=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: language0=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: market=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: ATL.SID.SALES= iMxiGMyW7sDBszdtMEyatYk7buGydr4hjvissnKiLec%3d; path=/; HttpOnly Set-Cookie: gdCassCluster.sePQKXdv2U=2; path=/ Set-Cookie: language0=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: market=en-US; domain=secureserver.net; expires=Tue, 27-Oct-2015 16:02:35 GMT; path=/ Set-Cookie: ATL.SID.SALES=iMxiGMyW7sDBszdtMEyatYk7buGydr4hjvissnKiLec%3d; path=/; HttpOnly Set-Cookie: gdCassCluster.sePQKXdv2U=2; path=/ Set-Cookie: mobile.redirect.browser=0; path=/ P3P: policyref="/w3c/p3p.xml", CP="COM CNT DEM FIN GOV INT NAV ONL PHY PRE PUR STA UNI IDC CAO OTI DSP COR CUR OUR IND" Date: Mon, 27 Oct 2014 16:02:34 GMT % echo "QUIT" | openssl s_client -connect www.secureserver.net:443 | head -10 ~ swlap1 depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify error:num=20:unable to get local issuer certificate DONE CONNECTED(00000003) --- Certificate chain 0 s:/C=US/ST=Arizona/L=Scottsdale/O=Special Domain Services, LLC/CN=*.secureserver.net i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority --- On Mon, Oct 27, 2014 at 1:21 PM, shawn wilson wrote: > Ok, got a few off list replies that secureserver.net is godaddy which > is fine - makes sense. I just wish this would link back to them easier > (some backup ns being something.godaddy.com or some SOA of an IP > listed in the spf being something.godaddy.com or whatever). > > Thank y'all for the info. > > On Mon, Oct 27, 2014 at 11:57 AM, shawn wilson wrote: >> We get lots of probes from subdomains of southwestdoor.com and >> secureserver.net 's SOA and I'm curious who these guys are? >> >> The only web page I could find was southwestdoor redirects to >> http://www.arcadiacustoms.com and then to http://arcadia-custom.com/ >> (a hardware company is causing unwanted network traffic - not unless >> they're owned) >> >> Traceroute for southwestdoor.com goes through secureserver.net and >> they have lots of references (in dns) to themselves, jomax.net and >> domaincontrol.com. >> >> Can someone give me a better picture of how this all fits together on >> a company level - as in how do these guys make money and why are they >> probing our network? I understand scans from ISPs and colos, but I >> can't directly identify these guys as either. From bzs at world.std.com Mon Oct 27 17:28:34 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 27 Oct 2014 13:28:34 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> Message-ID: <21582.32962.276867.80970@world.std.com> On October 24, 2014 at 19:34 drc at virtualized.org (David Conrad) wrote: > Barry, > > On Oct 24, 2014, at 12:13 PM, Barry Shein wrote: > > I believe this never-ending quest for more reliable domain > > registration data is being driven by intellectual property lawyers to > > lower the cost of serving those they see as infringers either by > > domain or web site content. > > I would agree that the intellectual property folks have interests in this area, however having sat through sessions on various illegal activities facilitated by domain names (e.g., trade in endangered species, child porn, illegal pharmacies, etc) as well as having been to anti-abuse meetings (e.g., MAAWG, APWG, RIPE abuse-wt, etc), I am fairly confident there are far more people interested in accurate registration data than merely intellectual property lawyers. Oh no! The Four Horsement of the Infocalypse! http://en.wikipedia.org/wiki/Four_Horsemen_of_the_Infocalypse Sure, "agree with me or you're a child porn enabler!" I just tend to doubt this effort will help much. It's just selling some idealized vision of domain registration data. At any rate, I'm not against better data, my concern is more in the realm of: At what cost? Who has access? Who specifically bears the cost of all this goodness? I think I mentioned this but in LA I was in a near shouting match with an IP lawyer whose specialty was brands protection who couldn't understand why service providers were so difficult to deal with when asked for customer info, take downs, whatever they wanted. I said hey, you're being paid like $300/hour to deal with this, you're offering me zero. You imagine this is just your little request but it's not, it's a time sinkhole as you chase words that rhyme with your client's brand or other potential business. One of the more sordid aspects of the law is that one can enact more and more stringent and time-consuming reporting etc rules and at some point it's just a free ride. Suddenly the law REQUIRES service providers to expend whatever effort it takes to provide accurate and timely discovery information. Meanwhile Verizon and other big telcos are getting like $500 per for taps etc, to the tune of tens of millions per month? http://www.forbes.com/sites/robertlenzner/2013/09/23/attverizonsprint-are-paid-cash-by-nsa-for-your-private-communications/ or http://tinyurl.com/q74oa7u I'm not against the concept, but it needs balance and it's reasonable to advocate. That doesn't make someone a child-porn enabler. Goodness costs money. > > Heck, I heard even some network operators would like to have accurate registration databases and I don't think many of those folks are intellectual property lawyers. > > > FWIW, my suggestion was to put the WHOIS data into the DNS (a new RR > > perhaps) under the control of whoever manages that DNS record and if > > someone needs more correct information then perhaps the registrars > > could provide it (perhaps for a fee) from the sales slips (so to > > speak.) > > You're too late: I believe there is a t-shirt that has the slogan "F* that, let's just put it in the DNS"... :) I suppose that's better than "I've never heard anyone suggest this but you!", so I'll take it! > > > It's just a sales record, not sure why some are trying to move heaven > > and earth to idealize the information and access to it. > > I disagree. Perhaps my age is showing, but I believe the whole point of the registration database is to provide contact information to allow someone to contact the registrant for whatever reason, e.g., "hey, stop that!". It's the old problem, crooks don't hand out business cards. And, again, at what cost, and to whom? > > > P.S. And of course the new WHOIS proposal involves creating classes of > > access to go along with improved correctness. > > That is one part of the outcome of ICANN's ongoing effort to try to fix the multiple decade long nightmare that is Whois, yes. It needs a public examination. This is a big change. It's reasonable to be suspicious that it will be turned into a privileged and expensive resource. > > > So only bona-fide > > lawyers with paid-up bar dues will be able to get at the info because, > > you know, lawyers, esq. > > I'm not sure such a wild mischaracterization of the _166 page_ proposal for "A Next Generation Registration Directory Service" is actually helpful. The whole question of registration data is extremely complicated with a vast array of mutually contradictory requirements. As I understand it, the tiered access proposal was largely driven by the requirement to deal with the differing privacy requirements/laws/customs/etc. across the planet (e.g., the EU data privacy directives). As with anything that suggests non-trivial change, there is much that is controversial in the proposal, however I suspect it would be more useful if the controversy was based in actual reality instead of snark. I read the recent 95 page version, and the previous 66 page (sixty-something) proposal. And I will go read the latest. But I don't think my characterization is mere snark. It also strikes me as having a lot of technical problems, policy wish-lists posing as technology. I think the effort needs to be joint with an IETF working group, a lot of the issues are beyond the capabilities of the ICANN group, that's clear from reading what I've read. > > For anyone actually interested, the actual proposal is at > > https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf > > (and to be clear, it is a proposal -- people are currently discussing what to do with it) Or snarking. > > Regards, > -drc > -- -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 goemon at anime.net Mon Oct 27 17:12:13 2014 From: goemon at anime.net (goemon at anime.net) Date: Mon, 27 Oct 2014 10:12:13 -0700 (PDT) Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21582.32962.276867.80970@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> Message-ID: On Mon, 27 Oct 2014, Barry Shein wrote: > > I disagree. Perhaps my age is showing, but I believe the whole point of the registration database is to provide contact information to allow someone to contact the registrant for whatever reason, e.g., "hey, stop that!". > It's the old problem, crooks don't hand out business cards. > And, again, at what cost, and to whom? If you can't be bothered to have correct contact info, your packets go into the scavenger queue. Or get redirected to a webpage explaining why your network is blocked until you correct it. Your customers will be the ones complaining to you. -Dan From rvandolson at esri.com Mon Oct 27 17:52:07 2014 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 27 Oct 2014 10:52:07 -0700 Subject: .mil postmaster Contacts? Message-ID: <20141027175207.GA15830@esri.com> We're seeing issues deliving email to certain .mil domains. MX hosts for these domains are not responding on port 25 and have verified from off-network as well. Anyone else seeing the same or can point me to a technical POC to start with? navy.mil, usmc.mil, uscg.mil are just a few that seem to be having issues. Ray From markjr at easydns.com Mon Oct 27 17:53:10 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Mon, 27 Oct 2014 13:53:10 -0400 Subject: RBL alert: impending sh*tshow for rbl.orbitrbl.com Message-ID: <544E8686.6080400@easydns.com> As some of you may know, we recently took over ZoneEdit.com and it's customer base. We've found a domain on the system: rbl.orbitrbl.com which is delegated to zoneedit nameservers, broken (it is not allowed to zone transfer from it's designated master), unresponsive (account owner is not answering email, has an address in Sri Lanka and no telephone number), is using excessive queries (~ >500M queries per day on a "free dns" domain) and attracting repeated, multiple DDoS attacks. As such, we will be wildcarding this zone and setting a long TTL fairly soon. If you're actually using this RBL in your MTAs, now's a good time to stop. (this RBL is broken on 5 out of it's 6 delegated nameservers across 3 separate providers). - mark -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From mikea at mikea.ath.cx Mon Oct 27 18:23:45 2014 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 27 Oct 2014 13:23:45 -0500 Subject: .mil postmaster Contacts? In-Reply-To: <20141027175207.GA15830@esri.com> References: <20141027175207.GA15830@esri.com> Message-ID: <20141027182345.GC7768@mikea.ath.cx> On Mon, Oct 27, 2014 at 10:52:07AM -0700, Ray Van Dolson wrote: > We're seeing issues deliving email to certain .mil domains. MX hosts > for these domains are not responding on port 25 and have verified from > off-network as well. > > Anyone else seeing the same or can point me to a technical POC to start > with? > > navy.mil, usmc.mil, uscg.mil are just a few that seem to be having > issues. When we (state gummint) had trouble delivering work-related mail to some .mil addresses in our state, I found that the best way was to look up the contacts on the installation's website, make a phone call, and ask for the IT people. We found that sometimes they shut mail down, sometimes higher HQ publish an overly wide firewall block list, and sometimes Stuff Just Happens. YMMV, as always. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From lowen at pari.edu Mon Oct 27 18:25:14 2014 From: lowen at pari.edu (Lamar Owen) Date: Mon, 27 Oct 2014 14:25:14 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch [OT] In-Reply-To: References: <5445AD63.7090400@lugosys.com> Message-ID: <544E8E0A.3070706@pari.edu> On 10/25/2014 04:55 PM, Matthew Petach wrote: > Completely agree on this point--but I fail to see why it has to be one > or the other? Why can't systemd have a --text flag to tell it to > output in ascii text mode for those of us who prefer it that way? It still logs to syslog, and syslog can still log to text. Systemd certainly writes a nice text /var/log/messages on my CentOS 7 system. There is also a --log-target command line option, where there are several possible targets. Further, the binary log is generated by journald, not by systemd itself, which can log directly to syslog without using the binary journal (see: http://fitzcarraldoblog.wordpress.com/2014/09/20/change-systemds-binary-logging-to-text-logging-in-sabayon-linux/ for how to do this in one particular Linux distribution, Sabayon). The more I dig into systemd, the less I dislike it. I'm still not thrilled, but it's not as bad as I first heard it was going to be. From itg at itechgeek.com Mon Oct 27 18:34:18 2014 From: itg at itechgeek.com (ITechGeek) Date: Mon, 27 Oct 2014 14:34:18 -0400 Subject: .mil postmaster Contacts? In-Reply-To: <20141027182345.GC7768@mikea.ath.cx> References: <20141027175207.GA15830@esri.com> <20141027182345.GC7768@mikea.ath.cx> Message-ID: Those all appear to be going through DISA's Enterprise Email system. http://www.disa.mil/Services/Computing/~/media/Files/DISA/Services/Computing/DECCServiceDeskContact.pdf If they don't have an option specifically for Enterprise Email, try contacting the extension for Oklahoma City. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Oct 27, 2014 at 2:23 PM, Mike A wrote: > On Mon, Oct 27, 2014 at 10:52:07AM -0700, Ray Van Dolson wrote: > > We're seeing issues deliving email to certain .mil domains. MX hosts > > for these domains are not responding on port 25 and have verified from > > off-network as well. > > > > Anyone else seeing the same or can point me to a technical POC to start > > with? > > > > navy.mil, usmc.mil, uscg.mil are just a few that seem to be having > > issues. > > When we (state gummint) had trouble delivering work-related mail to some > .mil > addresses in our state, I found that the best way was to look up the > contacts > on the installation's website, make a phone call, and ask for the IT > people. > > We found that sometimes they shut mail down, sometimes higher HQ publish an > overly wide firewall block list, and sometimes Stuff Just Happens. > > YMMV, as always. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > From lowen at pari.edu Mon Oct 27 18:39:19 2014 From: lowen at pari.edu (Lamar Owen) Date: Mon, 27 Oct 2014 14:39:19 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> References: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> Message-ID: <544E9157.9090704@pari.edu> On 10/27/2014 11:35 AM, Jay Ashworth wrote: > I will counter with "you wouldn't be running a "real" distro in that > case anyway; you'd be running something super trimmed down, and > possibly custom built, or based on something like CoreOS, that only > does one job. Well. Hmm, now this one I wasn't aware of.... this tidbit here has made this thread worthwhile to me, as we work on developing some clustered 'things' for use here..... CoreOS wasn't even on the 'look at this at some point in time' list before, but it is now..... Thanks, Jay. From mfidelman at meetinghouse.net Mon Oct 27 18:49:38 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 27 Oct 2014 14:49:38 -0400 Subject: Linux: concerns over systemd [OT] In-Reply-To: <544E9157.9090704@pari.edu> References: <13660814.626.1414424130678.JavaMail.root@benjamin.baylink.com> <544E9157.9090704@pari.edu> Message-ID: <544E93C2.4040103@meetinghouse.net> Lamar Owen wrote: > On 10/27/2014 11:35 AM, Jay Ashworth wrote: >> I will counter with "you wouldn't be running a "real" distro in that >> case anyway; you'd be running something super trimmed down, and >> possibly custom built, or based on something like CoreOS, that only >> does one job. Well. > > Hmm, now this one I wasn't aware of.... this tidbit here has made this > thread worthwhile to me, as we work on developing some clustered > 'things' for use here..... CoreOS wasn't even on the 'look at this at > some point in time' list before, but it is now..... Thanks, Jay. Funny, and here my reaction is just the opposite - to remove CoreOS from my list of things to look at. Cheers, Miles Fidelman From bzs at world.std.com Mon Oct 27 18:52:39 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 27 Oct 2014 14:52:39 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> Message-ID: <21582.38007.896031.28872@world.std.com> On October 27, 2014 at 10:12 goemon at anime.net (goemon at anime.net) wrote: > On Mon, 27 Oct 2014, Barry Shein wrote: > > > I disagree. Perhaps my age is showing, but I believe the whole point of the registration database is to provide contact information to allow someone to contact the registrant for whatever reason, e.g., "hey, stop that!". > > It's the old problem, crooks don't hand out business cards. > > And, again, at what cost, and to whom? > > If you can't be bothered to have correct contact info, your packets go > into the scavenger queue. Or get redirected to a webpage explaining why > your network is blocked until you correct it. > > Your customers will be the ones complaining to you. When all you have is a hammer the entire world looks like a nail! Typical estimates are that around 30-40% of WHOIS data is useless (for what purpose tho?) ranging from out of date (they don't live there any more, etc) to terribly incomplete, to probably fraudulent (Daffy Duck owns many domains, so does Frodo Baggins.) So long as the bill gets paid, or was paid 10 years forward, etc., it tends to not get reviewed. So is your proposal to block 30-40% of all domains? Whose customers will be complaining? But this isn't about that. As I said in a previous note I have no problem with better data as a concept. Few disagree with that, the devil is in the details. The issues are at what cost, at whose cost, who gets access to the data (that's changing, get ready for "NOT AUTHORIZED" as a response to a WHOIS query), what is good data (is listing an agency whose purpose is to exist but not reveal your identity good enough? There are many of those, it's become a big business), where should it be stored, who has custodial responsibility, privacy responsibility, how can that be enforced (contract, most likely, but how are contracts enforced in countries whose name you can't pronounce correctly), it's even much more complicated than that (cctlds who don't even recognize a contracting authority), etc. etc. etc. Oh and let's not get started on things like the EU's data privacy requirements. Well, actually, we have to. You're welcome to join the fray, but leave the hammer at home. -- -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 brunner at nic-naa.net Mon Oct 27 20:21:11 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 27 Oct 2014 13:21:11 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> Message-ID: <544EA937.3050601@nic-naa.net> On 10/27/14 10:12 AM, goemon at anime.net wrote: > > If you can't be bothered to have correct contact info, your packets go > into the scavenger queue. Or get redirected to a webpage explaining > why your network is blocked until you correct it. > > Your customers will be the ones complaining to you. the (icann accredited) registrar which accepted {bogus|non-verified|accurate} registrant data at some point in time less than 10 years ago which is now {bogus|non-verified|accurate|aged-out} is likely to be providing dns for the domain in question, or the dns is likely to be provided by the registrant, so the "packets [DO NOT] go into the scavenger queue." NOR are they "redirected ..." it helps to recognize that there is a problem, and the absence of subject matter expertise contributes to the problem. trans: you are part of the problem. -e From owen at delong.com Mon Oct 27 20:57:14 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Oct 2014 13:57:14 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <544A9573.3000700@nic-naa.net> References: <54497E03.5020207@nic-naa.net> <544A9573.3000700@nic-naa.net> Message-ID: > On Oct 24, 2014, at 11:07 AM, Eric Brunner-Williams wrote: > > On 10/23/14 7:27 PM, David Conrad wrote: >>> >in other words, the bc and ispc were, and for the most part, imho, remain captive properties of the intellectual property constituency. >> Here, Eric is suggesting the intellectual property folks are driving policy issues on behalf of the folks interested in security/stability of e-commerce and as well as ISPs and connectivity providers. I have no reason to doubt Eric's opinion as I've not been involved enough in that part of ICANN and he has. >> > > somethings get lost in translation. even the best of translations. > > i suggest that the agenda of the intellectual property constituency is the agenda of business and internet service provider constituencies, as measured (in 2008) by staff summary of policy initiatives and votes on policy by the constituencies of the gnso, due to the very high correlations of the constituency votes of record, but it could all be mere, though persistent, coincidence. Perhaps this is more indicative of the fact that the fractions of the business and ISP constituencies that actually care enough to devote resources to ICANN meetings and such are, in fact, those businesses most closely tied with the Intellectual Property interests as the rest of the world basically doesn’t give a damn unless something goes horribly wrong and DNS stops doing what they expect. > a nuance is whether the accuracy of whois data (a problem dave crocker and i and others tried to fix at the los angeles icann meeting in november 2001, and which, as hordes of the undead, lives on and on and on) is what is generally meant by "security and stability", or if the value of accuracy of whois data has significant value to parties other than the intellectual property constituency. I don’t think it is all that is meant by that term, but certainly it is a component. > were the oarc meeting not held, by mere coincidence of course, in a particular hotel in los angeles last week, fewer people with operational roles might have been present. True. I think that as a general rule, operators are conspicuously absent from most ICANN proceedings. > the protocol supporting organization tired of having a voting responsibility on the icann board and got the bylaws changed in 2003 to eliminate itself as a supporting organization holding voting seats on the icann board and created a technical advisory body tasked to periodically provide non-voting persons to offer technical advice to the icann board. Which I think says more about the tedium and general lack of relevance of most of what ICANN does to the operational and technical constituencies than it says about the protocol supporting organization. > i suppose a choice that addresses the problem warren noted is to ask if there is a continued need for operators-or-whatever-as-a-voting-body within the gnso. as much as i participated in the gnso reform program (which may have simply improved some of the ornamental decoration and changed some names from "constituencies" to "stakeholder groups" without changing the balance of forces david noted -- trademark protection vs volume sales -- and would prefer to see the ispcp develop a broader agenda than mere marks protection), taking a step back i'm no longer convinced that operational issues, and therefore operators, have any place, usefully, in the generic domain name supporting organization. Now there’s a lovely thought… We don’t like what few operators who haven’t walked away in disgust are telling us, so, it’s perhaps better to call their voices irrelevant and simply dismiss them as a non-relevant constituency. Owen From goemon at anime.net Mon Oct 27 20:32:15 2014 From: goemon at anime.net (goemon at anime.net) Date: Mon, 27 Oct 2014 13:32:15 -0700 (PDT) Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <544EA937.3050601@nic-naa.net> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> <544EA937.3050601@nic-naa.net> Message-ID: On Mon, 27 Oct 2014, Eric Brunner-Williams wrote: > On 10/27/14 10:12 AM, goemon at anime.net wrote: >> If you can't be bothered to have correct contact info, your packets go into >> the scavenger queue. Or get redirected to a webpage explaining why your >> network is blocked until you correct it. >> >> Your customers will be the ones complaining to you. > the (icann accredited) registrar which accepted {bogus|non-verified|accurate} > registrant data at some point in time less than 10 years ago which is now > {bogus|non-verified|accurate|aged-out} is likely to be providing dns for the > domain in question, or the dns is likely to be provided by the registrant, so > the "packets [DO NOT] go into the scavenger queue." NOR are they "redirected > ..." I should clarify I was thinking about whois on the IP blocks and/or ASN. not dns for domain names. if your network is spewing sewage, there should be some way to contact you. if you are uninterested in being contacted, there's always RBLs I guess. -Dan From ttauber at 1-4-5.net Mon Oct 27 21:20:11 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 27 Oct 2014 17:20:11 -0400 Subject: [NANOG-announce] NANOG 63 - San Antonio - Call for Presentations is Open! Message-ID: Greetings NANOG Folks, It was great to see so many of you (~700) at NANOG 62 in Baltimore. NANOG will hold its 63rd meeting in San Antonio, TX on February 2-4, 2015, hosted by CyrusOne. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 63 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: Date Event/Deadline Oct. 27, 2014 CFP Opens for NANOG 63 Dec. 05, 2014 CFP Deadline #1: Presentation Abstracts Due Dec. 12, 2014 CFP Topic List Posted Jan. 02, 2015 CFP Deadline #2: Presentation Slides Due Jan. 09, 2015 Meeting Agenda Published Jan. 30, 2015 Speaker FINAL presentations to PCTool or speaker-support Feb. 02, 2015 Lightning Talk Submissions Open (Abstracts Only) NANOG 63 submissions are welcome on the Program Committee Site or email me if you have questions. See the detailed NANOG63 Call for Presentations for more information. Let's see each other in San Antonio where, apparently, the typical high temps in February are 65F/18C. Thanks, Tony Tauber Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From gdendy at equinix.com Mon Oct 27 22:03:17 2014 From: gdendy at equinix.com (Greg Dendy) Date: Mon, 27 Oct 2014 15:03:17 -0700 Subject: Now Hiring At Equinix: Network Architect Message-ID: <941BBB10-B5F4-4392-BFFA-695EA25EAE69@equinix.com> Equinix is now hiring a Network Architect to help design the next-generation of interconnection platforms, come join a great team. http://equinix.hodesiq.com/job_detail.asp?JobID=4652823&user_id= Interested, or know someone that is? Apply online, or let me know. Greg From drc at virtualized.org Mon Oct 27 22:34:24 2014 From: drc at virtualized.org (David Conrad) Date: Mon, 27 Oct 2014 15:34:24 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <21582.32962.276867.80970@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> Message-ID: <7ED5F5DC-69BB-4541-A7BA-E19686E2043F@virtualized.org> Barry, On Oct 27, 2014, at 10:28 AM, Barry Shein wrote: > Oh no! The Four Horsement of the Infocalypse! Being dismissive of concerns related to illegal activities that make use of the DNS does not, of course, make those concerns go away. A number of folks make use of the registration database in attempting to address illegal activities, as such it seems to me that it would be useful if that database was accurate. > It's the old problem, Not really. > crooks don't hand out business cards. Registration data is used to identify registrants, not crooks. As Mark Andrews pointed out, there are uses for identifying non-crook registrants. In rare cases, registrants are crooks and while I'd agree the sophisticated crooks will find ways around any requirements for accuracy, I believe there is value to having accuracy in the general case. Or are you arguing we should simply remove Whois as a service available to the Internet? > And, again, at what cost, and to whom? The cost obviously depends on the requirements and implementation. The whom is and will always be the registrant. However, for the vast majority of registrants with a handful of domains, the costs are likely to be in the pennies. Granted, for the domainers with huge portfolios, the costs may be significant, however that is a cost of doing that particular business. >> That is one part of the outcome of ICANN's ongoing effort to try to fix the multiple decade long nightmare that is Whois, yes. > It needs a public examination. This is a big change. Agreed! And, in particular, it would be nice if network operators, who I believe make non-trivial use of Whois examine that change and determine whether the changes meet their requirements and if not, dare I say, participate in ICANN to make sure it does. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From warren at kumari.net Mon Oct 27 23:01:54 2014 From: warren at kumari.net (Warren Kumari) Date: Mon, 27 Oct 2014 19:01:54 -0400 Subject: An update from the ICANN ISPCP meeting... In-Reply-To: <54497E03.5020207@nic-naa.net> References: <54497E03.5020207@nic-naa.net> Message-ID: On Thu, Oct 23, 2014 at 6:15 PM, Eric Brunner-Williams wrote: > some history. > > at the montevideo icann meeting (september, 2001), there were so few > attendees to either the ispc (now ispcp) and the bc (still bc), that these > two meetings merged. at the paris icann meeting (june, 2008) staff presented > an analysis of the voting patters of the gnso constituencies -- to my > non-surprise, both the bc and the ispc votes (now ispcp) correlated very > highly with the intellectual property constituency, and unlike that > constituency, originated very little in the way of policy issues for which > an eventual vote was recorded. in other words, the bc and ispc were, and for > the most part, imho, remain captive properties of the intellectual property > constituency. > > this could change, but the isps that fund suits need to change the suits > they send, the trademark lawyer of eyeball network operator X is not the vp > of ops of network operator X. Unless folk here *like* having their views represented as being aligned with intellectual property folk? Well, do you? If not, come to an ICANN meeting and say so... W > > meanwhile, whois, the udrp, and other bits o' other-people's-business-model > take up all the available time. > > eric > > > > On 10/23/14 2:58 PM, Warren Kumari wrote: >> >> Those of y'all who were at NANOG62 may remember a presentation from the >> ICANN >> Internet Service Provider and Connectivity Providers Constituency (ISPCP). >> >> I feel somewhat bad because I misunderstood what they were sayingin, >> and kinda lost my cool during the preso. Anyway, the ISPCP met at >> ICANN 51 last week. Unfortunately I was not able to attend, but the >> meeting audio stream is posted at: >> http://la51.icann.org/en/schedule/tue-ispcp >> >> If you'd rather read than listen, the transcript is posted here: >> >> http://la51.icann.org/en/schedule/tue-ispcp/transcript-ispcp-14oct14-en.pdf >> >> I snipped a bit that mentions NANOG: >> >> The next outreach experience that we had was at NANOG. NANOG, as you >> may know, is the North American Network Operators Group, an area where >> we really wanted to make an impact because it is the network operators >> groups that can really bring the insight that we need to act on being a >> unique >> and special voice within the ICANN community on issues that matter to ISPs >> around some of the things that are on our agenda today, such as universal >> access, such as name collisions. And we wanted to get more technical >> voices >> in the mix and more resources in the door so that we could make a better >> impact there. >> A lot of what we received when we stood up to give our presentation were >> messages from people who had attempted to engage in ICANN in the past or >> attempted to engage in the ISPCP in the past and had had very difficult >> time >> doing. They said when you come into this arena you spend so much time >> talking about process, so much time talking about Whois and what board >> seats, about what needs to happen around transparency. I'm a technical >> guy, >> I want to focus on technical issues and I don't have a unique venue for >> being >> able to do that. >> So we spent some time as a group trying to figure out how we can address >> that because we do need those voices. Our goal has been to take the >> feedback that we receive from NANOG and create an action plan to make >> sure that we can pull in voices like that and go back to the NOG >> community, >> go back to the technical operators community, bring them on board and say >> we've got a different path for you. >> >> >> >> Anyway, go listen / read the full transcript if you are so inclined... >> >> W >> >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From bzs at world.std.com Tue Oct 28 00:34:35 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 27 Oct 2014 20:34:35 -0400 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <7ED5F5DC-69BB-4541-A7BA-E19686E2043F@virtualized.org> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> <7ED5F5DC-69BB-4541-A7BA-E19686E2043F@virtualized.org> Message-ID: <21582.58523.763611.909951@world.std.com> On October 27, 2014 at 15:34 drc at virtualized.org (David Conrad) wrote: > Barry, > > On Oct 27, 2014, at 10:28 AM, Barry Shein wrote: > > Oh no! The Four Horsement of the Infocalypse! > > Being dismissive of concerns related to illegal activities that make use of the DNS does not, of course, make those concerns go away. A number of folks make use of the registration database in attempting to address illegal activities, as such it seems to me that it would be useful if that database was accurate. Leading with "child porn" etc as a first-mentioned motivation strikes me as an attempt to snatch the moral high ground rather than discuss the issues -- oh and if you disagree with me you must be ok with child porn. I've chased child pornographers with LEO. By and large they are very, very careful about their identities. You're not going to just do a WHOIS query and jot down their address and phone number and pay them a visit. At any rate, we can all drive at 20MPH max and think of how many thousands of lives that would save every year...etc. Disagree? Do you want people to die?!? And so forth. That there's an intent or possibility to improve criminal investigations doesn't necessarily justify the means. And I still believe a lot of the energy behind the WHOIS rewrite has come from the intellectual property crowd (to reduce the cost of discovery) tho yes law enforcement loves better identity sources particularly if it's on someone else's budget. > > > It's the old problem, > > Not really. > > > crooks don't hand out business cards. > > Registration data is used to identify registrants, not crooks. As Mark Andrews pointed out, there are uses for identifying non-crook registrants. In rare cases, registrants are crooks and while I'd agree the sophisticated crooks will find ways around any requirements for accuracy, I believe there is value to having accuracy in the general case. You're still just repeating potential motivations rather than telling us how these changes will accomplish those goals, and at what cost. How is any of that being accomplished by limiting access to the WHOIS data? >From page 21 of the Final Report: "...the EWG recommends abandoning today's WHOIS model -- giving every user the same anonymous public access to (too often inaccurate) gTLD registration data. Instead, the EWG recommends a paradigm shift whereby gTLD registration data is collected, validated and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use." (me: EWG = Expert Working Group) Ok, admittedly there's a lot more to the report than we're discussing here and the only fair way to review it is to read it which I recommend, again that URL: https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf or http://tinyurl.com/kdjdu7c Don't get me wrong, I consider it by and large well-intentioned. But that doesn't mean we can't disagree on some recommendations. > > Or are you arguing we should simply remove Whois as a service available to the Internet? > > > And, again, at what cost, and to whom? > > The cost obviously depends on the requirements and implementation. > > The whom is and will always be the registrant. However, for the vast majority of registrants with a handful of domains, the costs are likely to be in the pennies. Granted, for the domainers with huge portfolios, the costs may be significant, however that is a cost of doing that particular business. What about charging those with need for access to the data? Once we've limited access to "authenticated requestors" why not charge a fee for that authenticated access? That was part of my suggestion to put the public data in the DNS. Public data accessed via the DNS is free (for some value of free, but not usage charged.) And it has roughly the accuracy and precision we experience today. For more accurate data you can pay for a record request. Up to and including presenting a court order though I would hope that's not the common case. > > >> That is one part of the outcome of ICANN's ongoing effort to try to fix the multiple decade long nightmare that is Whois, yes. I don't see it as a "nightmare". It very much reflects the spirit of the internet. Much of it is free and voluntary and worth more than you paid for it. It's only when some imagine some specific, valuable use that they might become frustrated. Shall we try to clean up google (et al) result accuracy also? > > It needs a public examination. This is a big change. > > Agreed! And, in particular, it would be nice if network operators, who I believe make non-trivial use of Whois examine that change and determine whether the changes meet their requirements and if not, dare I say, participate in ICANN to make sure it does. I don't think we're very far apart. We just have slightly different value weightings on some points. > > Regards, > -drc > -- -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 chuckchurch at gmail.com Tue Oct 28 01:03:15 2014 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 27 Oct 2014 21:03:15 -0400 Subject: .mil postmaster Contacts? In-Reply-To: <20141027175207.GA15830@esri.com> References: <20141027175207.GA15830@esri.com> Message-ID: <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> You sure it's not a DNS issue? I've had problems resolving various *.disa.mil sites today. Google DNS claims they don't exist. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson Sent: Monday, October 27, 2014 1:52 PM To: nanog at nanog.org Subject: .mil postmaster Contacts? We're seeing issues deliving email to certain .mil domains. MX hosts for these domains are not responding on port 25 and have verified from off-network as well. Anyone else seeing the same or can point me to a technical POC to start with? navy.mil, usmc.mil, uscg.mil are just a few that seem to be having issues. Ray From mfidelman at meetinghouse.net Tue Oct 28 01:10:20 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 27 Oct 2014 21:10:20 -0400 Subject: Linux: concerns over systemd adoption and Debian's decision to switch In-Reply-To: <28793350.624.1414423453599.JavaMail.root@benjamin.baylink.com> References: <28793350.624.1414423453599.JavaMail.root@benjamin.baylink.com> Message-ID: <544EECFC.3040500@meetinghouse.net> Jay Ashworth wrote: > ----- Original Message ----- >> From: "Chris Adams" >> Once upon a time, Jay Ashworth said: >>> "Try to do everything *inside PID 1*" is the real problem. >> And that is not what systemd is doing; make sure you know what you are >> complaining about. systemd-the-project != systemd-the-pid-1. PID 1 is >> responsible for managing services/daemons, and AFAIK that's all >> systemd's PID 1 does. > Indeed. I was quoting (I thought) better read people than me. If that's the > case, I retract about 25% of my distaste for it. > Well, yeah... but there's this huge (and growing) network of interlocking dependencies, and, at least at the moment, no way to avoid installing systemd as PID1 during a fresh Debian install (no installer choice, and a bug in debootstrap that prevents preseeding). So, yes, you can uninstall systemd as PID1, but it sure seems to be rather difficult. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From marka at isc.org Tue Oct 28 01:24:13 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 28 Oct 2014 12:24:13 +1100 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: Your message of "Mon, 27 Oct 2014 20:34:35 -0400." <21582.58523.763611.909951@world.std.com> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> <7ED5F5DC-69BB-4541-A7BA-E19686E2043F@virtualized.org> <21582.58523.763611.909951@world.std.com> Message-ID: <20141028012414.4E43B22971F6@rock.dv.isc.org> Whois's primary purpose is to keep the network running. CP, IP, LEO are all secondary issues. This tends to get lost. I can easily contact all the TLD operators using whois data and do so from time to time when I see issues with the servers. The one time I couldn't (both email addresses bounced) was reported to IANA who are working on getting the contact details corrected. Whois data for other zones is a real pain in the back side to get let alone process. .GOV just tells you if the zone exists. This is a !@#$!@#@$# joke. They are government departments. They should be contactable without having to depend upon web sites being up as sometimes you are complaining about the sites being down. For those of you who are US citizens please complain to your representatives about this. Mark -- 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 Tue Oct 28 02:04:35 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 27 Oct 2014 19:04:35 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <5526169E-D263-4132-A809-0B0A6FCE842F@virtualized.org> <21582.32962.276867.80970@world.std.com> <544EA937.3050601@nic-naa.net> Message-ID: <544EF9B3.4000604@nic-naa.net> On 10/27/14 1:32 PM, goemon at anime.net wrote: > [snip] > I should clarify I was thinking about whois on the IP blocks and/or > ASN. not dns for domain names. > > if your network is spewing sewage, there should be some way to contact > you. if you are uninterested in being contacted, there's always RBLs I > guess. As both David and Barry have observed, the interest in useful "authorship" information (origin, authority, etc) for name-to-resource associations need not be limited to third-parties engaged in prosecution of trademarks infringement or criminal laws. Thank you for your patience in this thread, and for the suggestion of the interest of first-parties. Eric From joelja at bogus.com Tue Oct 28 04:24:56 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 27 Oct 2014 21:24:56 -0700 Subject: NOC Calendar In-Reply-To: <30ACD0D6-DF8A-45F7-834B-478933A01201@delong.com> References: <30ACD0D6-DF8A-45F7-834B-478933A01201@delong.com> Message-ID: <544F1A98.6080103@bogus.com> On 10/27/14 9:27 AM, Owen DeLong wrote: > There are boxes that do that, but it’s really not a good solution… Here’s why: > > 1. TV signals in NTSC max out at 640x480. In ATSC, you get up to 1920x1080. > Many monitors today are capable of 2560x1440 or more. > > 2. It’s expensive and has few advantages over a traditional KVM switch. > > 3. An HDMI switcher and graphic cards with HDMI output are not particularly hard > to find these days. DVI->HDMI is also relatively easy if you have trouble getting > HDMI out of the machine. This is a much less expensive solution. > > Its fairly trivial to get VM video out to HDMI if you’re willing to dedicate hardware to the > task. It is pretty trivial at this point to have a network attached device serve as a remote display for essentially arbitrary sources. There's no real point imho in attaching to any machine other than the one directly in front of you over anything other than ip protocol. > > Owen > >> On Oct 24, 2014, at 7:38 AM, chris wrote: >> >> I was looking into something like this a while back and one thing that >> didnt seem to exist but I thought would be cool is if you could have a x86 >> box or appliance that could take video output of lets say a couple virtual >> machines and encode it into a standard TV signal so your average TV with a >> builtin tuner and have each VM's display encoded into a different TV >> channel. This way you could throw up TV's everywhere and easily change >> whats displayed at any time without having to have devices plugged into >> every TV. >> >> If this already exists or someone has built anything like this I would love >> to hear about it. >> >> - chris >> >> On Fri, Oct 24, 2014 at 10:07 AM, James Wininger >> wrote: >> >>> Does anyone on the list have a reference to a good "NOC" calendar? What I >>> mean by that is a calendar that is view only for the NOC, but looks "good" >>> on a larger LCD panel display. >>> >>> Ideally it would automatically rotate on a given schedule (say 6am), and >>> then show only that days scheduled events, there would be no need for the >>> NOC to interact with the calendar, just consume the data. >>> >>> Perhaps it would be color coded to show "DWDM work", vs MPLS work, or even >>> "new installs". But the idea is that the NOC would have readily accessible >>> "view only" at a glance. They would not have to load up outlook, go to >>> calendar, select the MPLS, install etc to see what work is happening. >>> >>> >>> -- >>> Jim Wininger >>> >>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From lathama at gmail.com Tue Oct 28 10:30:58 2014 From: lathama at gmail.com (Andrew Latham) Date: Tue, 28 Oct 2014 05:30:58 -0500 Subject: inexpensive KVMoIP In-Reply-To: <20141024144252.GB2179@2bithacker.net> References: <20141024144252.GB2179@2bithacker.net> Message-ID: I too like the Spider regardless of it's Java issues. It does accept SSH to Serial Console so there is a non-Java way to use it. If I can, serial console redirection is preferred but all of my Supermicro systems have the IPMI onboard. Expect to see more solutions use tools like http://guac-dev.org/ in the very near future. On Fri, Oct 24, 2014 at 9:42 AM, Chip Marshall wrote: > On 2014-10-23, Jared Mauch sent: >> Having recently encountered a problem with a machine, I’m >> looking for an inexpensive KVMoIP device to place within a >> facility to take VGA/USB Keyboard for a single host scale. >> Ideally something that can be properly placed on the internet, >> but that’s not a showstopper. >> >> If you’re willing to loan me one for a week or two as well, >> let me know too so I can ship it to the site and recover my >> machine. > > I've used Lantronix Spiders in the past, they're not bad. > > I'm curious if anyone knows of one that doesn't use Java for the > client though. With things like NoVNC and Guacamole out there > now, it seems like a HTML5 based remote KVM should be possible > and not a nightmare to work with. > > -- > Chip Marshall > http://2bithacker.net/ -- ~ Andrew "lathama" Latham lathama at lathama.com http://lathama.net ~ From jbates at paradoxnetworks.net Tue Oct 28 14:38:53 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Tue, 28 Oct 2014 09:38:53 -0500 Subject: Department of Education contact (BOGON listing)? Message-ID: <544FAA7D.90005@paradoxnetworks.net> Anyone have a good contact? I emailed the whois for the IP network but haven't heard back yet. Didn't find any contact info in whois for ed.gov. :( ed.gov. 86400 IN NS eduftcdnsp01.ed.gov. ed.gov. 86400 IN NS eduftcdnsp02.ed.gov. ed.gov. 86400 IN NS eduptcdnsp01.ed.gov. ed.gov. 86400 IN NS eduptcdnsp02.ed.gov. dig: couldn't get address for 'eduftcdnsp01.ed.gov' Unable to reach their nameservers from 104/8 networks. Other networks are fine. Jack Bates Paradox Networks From jra at baylink.com Tue Oct 28 14:59:39 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 28 Oct 2014 10:59:39 -0400 (EDT) Subject: Linux: concerns over systemd [OT] In-Reply-To: <544E93C2.4040103@meetinghouse.net> Message-ID: <25443017.719.1414508379657.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Miles Fidelman" > > Hmm, now this one I wasn't aware of.... this tidbit here has made this > > thread worthwhile to me, as we work on developing some clustered > > 'things' for use here..... CoreOS wasn't even on the 'look at this at > > some point in time' list before, but it is now..... Thanks, Jay. > > Funny, and here my reaction is just the opposite - to remove CoreOS > from my list of things to look at. I am happy and sad for you both. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From dwhite at olp.net Tue Oct 28 15:31:11 2014 From: dwhite at olp.net (Dan White) Date: Tue, 28 Oct 2014 10:31:11 -0500 Subject: Department of Education contact (BOGON listing)? In-Reply-To: <544FAA7D.90005@paradoxnetworks.net> References: <544FAA7D.90005@paradoxnetworks.net> Message-ID: <20141028153111.GD3634@dan.olp.net> On 10/28/14 09:38 -0500, Jack Bates wrote: >Anyone have a good contact? I emailed the whois for the IP network but >haven't heard back yet. Didn't find any contact info in whois for >ed.gov. :( > >ed.gov. 86400 IN NS eduftcdnsp01.ed.gov. >ed.gov. 86400 IN NS eduftcdnsp02.ed.gov. >ed.gov. 86400 IN NS eduptcdnsp01.ed.gov. >ed.gov. 86400 IN NS eduptcdnsp02.ed.gov. >dig: couldn't get address for 'eduftcdnsp01.ed.gov' > >Unable to reach their nameservers from 104/8 networks. Other networks >are fine. I also cannot retrieve glue records, but have them cached on my server: Fails (+trace implies +dnssec however): dig +short +trace ed.gov ns Works: ~$ dig @ns.olp.net ed.gov ns ;; ANSWER SECTION: ed.gov. 3478 IN NS eduptcdnsp01.ed.gov. ed.gov. 3478 IN NS eduftcdnsp02.ed.gov. ed.gov. 3478 IN NS eduftcdnsp01.ed.gov. ed.gov. 3478 IN NS eduptcdnsp02.ed.gov. ;; ADDITIONAL SECTION: eduftcdnsp01.ed.gov. 26896 IN A 165.224.21.6 eduftcdnsp01.ed.gov. 26896 IN AAAA 2610:e8:907f:1:cd99:4fb7:bb7:2213 eduftcdnsp02.ed.gov. 26896 IN A 165.224.21.5 eduftcdnsp02.ed.gov. 26896 IN AAAA 2610:e8:907f:1:d093:1118:adf3:7473 eduptcdnsp01.ed.gov. 26896 IN A 165.224.212.6 eduptcdnsp01.ed.gov. 26896 IN AAAA 2610:e8:9080:1:88dc:90ef:b68:490 eduptcdnsp02.ed.gov. 26896 IN A 165.224.212.5 eduptcdnsp02.ed.gov. 26896 IN AAAA 2610:e8:9080:1:8c49:4c6a:b596:f07b The servers are responding: ~$ dig @165.224.21.6 www.ed.gov ;; ANSWER SECTION: www.ed.gov. 3600 IN CNAME www.ed.gov.adtihosting.com. edtihosting.com is not retrievable in whois either, but its dns is cached as well. Their webpage (www.adtihosting.com) advertises itself as "Localweb.com", and their website lists this contact information: Departments Technical Support: For questions relating to setting up a new account or questions about existing accounts please contact our technical department at 1-800-525-0031 or via e-mail support at localweb.com -- Dan White From jra at baylink.com Tue Oct 28 15:50:50 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 28 Oct 2014 11:50:50 -0400 (EDT) Subject: OT: FOLO: LWN on Debian on multiple inits (systemd, etc) Message-ID: <25605544.845.1414511450344.JavaMail.root@benjamin.baylink.com> Pursuant to our other ongoing WW thread: http://lwn.net/Articles/616571/ The comments on this come down rather solidly on both sides of the fence, and most of them are relatively thoughful. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From digitallystoned at gmail.com Tue Oct 28 16:03:38 2014 From: digitallystoned at gmail.com (N M) Date: Tue, 28 Oct 2014 11:03:38 -0500 Subject: Packet Loss in Atlanta Message-ID: Hello nanog, I am getting reports from friends of mine in the ISP community that there are some issues in Atlanta with high latency and packet loss.. I don't see anything on my link to 56 Marietta but I was wondering if anyone else saw any problems out that way? Thanks in advance Nathan From rvandolson at esri.com Tue Oct 28 16:49:46 2014 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 28 Oct 2014 09:49:46 -0700 Subject: .mil postmaster Contacts? In-Reply-To: <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> References: <20141027175207.GA15830@esri.com> <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> Message-ID: <20141028164946.GA5284@esri.com> It *might* have been. Things cleared up yesterday. I initially thought it was the result of disabling DNSSEC on our primary resolvers, but am less certain that was the "fix" now as I don't see any issues with their config (per dnsviz). Ray On Mon, Oct 27, 2014 at 09:03:15PM -0400, Chuck Church wrote: > You sure it's not a DNS issue? I've had problems resolving various > *.disa.mil sites today. Google DNS claims they don't exist. > > Chuck > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson > Sent: Monday, October 27, 2014 1:52 PM > To: nanog at nanog.org > Subject: .mil postmaster Contacts? > > We're seeing issues deliving email to certain .mil domains. MX hosts for > these domains are not responding on port 25 and have verified from > off-network as well. > > Anyone else seeing the same or can point me to a technical POC to start > with? > > navy.mil, usmc.mil, uscg.mil are just a few that seem to be having issues. > > Ray From jeremy.knapp at gmail.com Tue Oct 28 18:05:57 2014 From: jeremy.knapp at gmail.com (Jeremy Knapp) Date: Tue, 28 Oct 2014 12:05:57 -0600 Subject: t-mobile help Message-ID: Would someone from T-Mobile be willing to contact me offline about some abuse issues we are having? Any help would be greatly appreciated. Thanks, Jeremy From ahebert at pubnix.net Wed Oct 29 13:14:07 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 29 Oct 2014 09:14:07 -0400 Subject: .mil postmaster Contacts? In-Reply-To: <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> References: <20141027175207.GA15830@esri.com> <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> Message-ID: <5450E81F.6040104@pubnix.net> On 10/27/14 21:03, Chuck Church wrote: > You sure it's not a DNS issue? I've had problems resolving various > *.disa.mil sites today. Google DNS claims they don't exist. > > Chuck > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson > Sent: Monday, October 27, 2014 1:52 PM > To: nanog at nanog.org > Subject: .mil postmaster Contacts? > > We're seeing issues deliving email to certain .mil domains. MX hosts for > these domains are not responding on port 25 and have verified from > off-network as well. > > Anyone else seeing the same or can point me to a technical POC to start > with? > > navy.mil, usmc.mil, uscg.mil are just a few that seem to be having issues. > > Ray Might be related to the news (CNN this morning) about the WH network being exploited for a few days now. They might be going after some .mil to and the tightening up of those networks may cause disruption. From chuckchurch at gmail.com Wed Oct 29 14:43:34 2014 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 29 Oct 2014 10:43:34 -0400 Subject: .mil postmaster Contacts? In-Reply-To: <5450E81F.6040104@pubnix.net> References: <20141027175207.GA15830@esri.com> <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> <5450E81F.6040104@pubnix.net> Message-ID: <014e01cff386$b7f57dc0$27e07940$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alain Hebert Sent: Wednesday, October 29, 2014 9:14 AM To: nanog at nanog.org Subject: Re: .mil postmaster Contacts? > Might be related to the news (CNN this morning) about the WH network being exploited for a few days now. > They might be going after some .mil to and the tightening up of those networks may cause disruption. I think it has to do with DNSSEC. The google DNS FAQ mentions (along with someone else who emailed me off-list) checking DNSVIZ for issues. So looking at: http://dnsviz.net/d/disa.mil/dnssec/ seems to indicate some issues. RRSET TTL MISMATCH I think they all are. Any DISA people on here? Using a non-Google DNS (which I guess isn't doing DNSSEC validation) does resolve the names fine. Chuck From rvandolson at esri.com Wed Oct 29 15:00:34 2014 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 29 Oct 2014 08:00:34 -0700 Subject: .mil postmaster Contacts? In-Reply-To: <014e01cff386$b7f57dc0$27e07940$@gmail.com> References: <20141027175207.GA15830@esri.com> <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> <5450E81F.6040104@pubnix.net> <014e01cff386$b7f57dc0$27e07940$@gmail.com> Message-ID: <20141029150034.GA25731@esri.com> On Wed, Oct 29, 2014 at 10:43:34AM -0400, Chuck Church wrote: > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alain Hebert > Sent: Wednesday, October 29, 2014 9:14 AM > To: nanog at nanog.org > Subject: Re: .mil postmaster Contacts? > > > Might be related to the news (CNN this morning) about the WH network being > exploited for a few days now. > > They might be going after some .mil to and the tightening up of those > networks may cause disruption. > > > I think it has to do with DNSSEC. The google DNS FAQ mentions (along with > someone else who emailed me off-list) checking DNSVIZ for issues. So > looking at: > http://dnsviz.net/d/disa.mil/dnssec/ > > seems to indicate some issues. RRSET TTL MISMATCH I think they all are. > Any DISA people on here? Using a non-Google DNS (which I guess isn't doing > DNSSEC validation) does resolve the names fine. > > Chuck I saw the same errors in dnsviz, but was unsure if they were sufficient to cause lookup failures (they were "warnings" only). # dig @8.8.8.8 disa.mil MX +dnssec ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 disa.mil MX +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9111 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;disa.mil. IN MX ;; ANSWER SECTION: disa.mil. 20039 IN MX 5 indal.disa.mil. disa.mil. 20039 IN MX 0 pico.disa.mil. disa.mil. 20039 IN MX 10 dnipro.disa.mil. disa.mil. 20039 IN RRSIG MX 8 2 86400 20141121222228 20141022222228 40608 disa.mil. lC2W9knYgviYJUKMYw9FJueUk4cR19spu7QsX3novmYrlOI70F0Rrzxm adU17tvfq1vbtzgYH0FriGIMdywPu/ssO7mK4KGhDj7pkQCcJZzlbrMe OlJOcC9mQcjgb6nt5KREBaIGzTGY0gA7AM6X2Ft/t9ZdsE/K+jNejgEc 4+M= I see the "ad" flag in the query response flags, so am thinking this lookup succeeded and was validated? I do note that once we disabled DNSSEC on our resolvers we were able to push mail out to these domains. May have been coincidental -- needs further testing. Ray From brunner at nic-naa.net Wed Oct 29 16:10:09 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 29 Oct 2014 09:10:09 -0700 Subject: A translation (was Re: An update from the ICANN ISPCP meeting...) In-Reply-To: <20141025120014.GB30231@gsp.org> References: <54497E03.5020207@nic-naa.net> <21578.42220.902698.749301@world.std.com> <20141025120014.GB30231@gsp.org> Message-ID: <54511161.7040306@nic-naa.net> On 10/25/14 5:00 AM, Rich Kulawiec wrote: > It might. So would removing the farce of 'private' domain registration. the venue where the applicable policy is currently under development is gnso-ppsai-pdp-wg at icann.org just to be tediously instructive, the policy applicable to gtlds is developed _only_ in the gnso, no where else, _only_ through the gnso's pdp, and no other process, and _only_ through a gnso chartered working group, and by no others. here, the catchy name is ppsai, an acronym for privacy & proxy services accreditation issues. so, if one sought to end proxy registration, one would subscribe to that mailing list and one would read the registration accreditation agreements (2013 and prior) and the wiki page, working documents, and even some of the mailing list archive, and then make the case -- as a gnso constituency member, e.g., ispcp -- that proxy registration creates externalities (costs to parties other than the registrants and registrars), and persuade (over time) sufficiently others in the working group, either of the correctness of your case, or the impossibility of the working group achieving "consensus" (as defined in the gnso pdp) on a report, intermediate or final, that is silent on the issue of unmet externalities. keep in mind, no amount of posturing by the aso fixtures or the passing ietf tourists or the pious at-large or concerned governments can be guaranteed to effect the gnso's consensus policies, or the process by which the gnso arrives at consensus policy. there have been 11 mails on the list this morning alone, as we try and distinguish between definition(s) of abuse in the terminal label (the "domain name") and of abuse in the resources mapped to the sequence of labels terminated by dot (the "fqdn"), and the duty, or lack of duty, of the registrar of record. the archives average about 100KB/month when gzip'd. there's my over-coffee tutorial on the subject. i've no longer a material interest in the subject matter, as i'm no longer responsible for an asn or an address allocation for an isp, nor for a registry, or a registrar, or a reseller. oh, least i forget, article 29 (european data protection directive, that is, privacy as a right arising from the treaty of europe) vs privacy arising from contract alone, e.g., between icann contracted parties. fun for everyone, and the betweenies, the oedc jurisdictions. eric From rdalleva at constantcontact.com Wed Oct 29 16:42:52 2014 From: rdalleva at constantcontact.com (D'Alleva, Ron) Date: Wed, 29 Oct 2014 16:42:52 +0000 Subject: cidr-report In-Reply-To: References: Message-ID: We noticed a large increase in prefixes this morning. Has anyone noticed any issues resulting from the increase? http://www.cidr-report.org/as2.0/#General_Status Thanks, Ron From mailing-lists at brianraaen.com Wed Oct 29 17:14:13 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 29 Oct 2014 13:14:13 -0400 Subject: NIST NTP Server List Message-ID: The list of NIST NTP servers is down for me, is anyone else seeing this? I'm getting a 404 error http://tf.nist.gov/tf-cgi/servers.cgi -- Brian Christopher Raaen Network Architect Zcorum From stu at actusa.net Wed Oct 29 17:16:58 2014 From: stu at actusa.net (Stuart Sheldon) Date: Wed, 29 Oct 2014 10:16:58 -0700 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: <5451210A.70401@actusa.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yeah, it looks like it's down stu On 10/29/2014 10:14 AM, Brian Christopher Raaen wrote: > The list of NIST NTP servers is down for me, is anyone else seeing this? > I'm getting a 404 error > http://tf.nist.gov/tf-cgi/servers.cgi > - -- "No problem is so big or so complicated that it can't be run away from!" -- Charles M. Schulz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJUUSEKAAoJEFKVLITDJSGSY8gP/jCGC2BT8oTmDLnxNVslL8wo VF1gB4WZm7xzJZk4PW/MbAn06TRADZGlO7d80a4lSBEAWTiq913d1G0LeXiRCgn6 o6dbgVjOgZWZ54J9jLwcSKaW6r0oXHO/DZ9PHKuZ0/t5A8I1YCiOQAD3fnBv2zmA PZjcKfGo3kuDfmdrJTGRKvvIWQkGno150XUzLjpC6DYd46zx8MrqXnuZLRatdPr+ pE/Z0moX35VUpC9y0pFrG9Pa2jjAIXRLbnDo6c8cp6noVGfQW+Xe8rX4+O7ddd27 CatcjsGKpiGd6Z1MtXvID5JBINHqsmqOgSRLpj62xl7MvSFMEyjeEyRVol+sxOj5 OBVObg4Pl4S7LrAJ1Bi9oK+CUW64E4jXpBfLejb+unv0jKF4RJSDec2ENskqkTb5 Z/p4kjlFAd9aWq37HVYKbm2DcK/XR4kzra4IgQ+LI1MWfLpm+voKxFVzWP/OxAxq ItYpQQ+tCtwAzQ245T7LvuWYXhIA/HiTct2DObEL6w/m2KPk8++zu0Zw5LZRWRAH FPhsOWwd0fw0i4dlGBCFnMvHzLrqvB64pA7H8x/X+V+vyAdELUXwAYn0lrFfgoJc WXZn99og5vqQnmv6r0ScGSoZER0lWpjaMIrkZoI8Pm5wS3fmjXpMhknlHqT8yPS/ pGJ4SQoXrVv0dPy65cpo =POmY -----END PGP SIGNATURE----- From john-nanog at peachfamily.net Wed Oct 29 17:22:29 2014 From: john-nanog at peachfamily.net (John Peach) Date: Wed, 29 Oct 2014 13:22:29 -0400 Subject: NIST NTP Server List In-Reply-To: <5451210A.70401@actusa.net> References: <5451210A.70401@actusa.net> Message-ID: <20141029132229.0edd80a2@jpeach-desktop.anbg.mssm.edu> http://downforeveryoneorjustme.com/http://tf.nist.gov/tf-cgi/servers.cgi No, it's not On Wed, 29 Oct 2014 10:16:58 -0700 Stuart Sheldon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Yeah, it looks like it's down > > stu > > > > On 10/29/2014 10:14 AM, Brian Christopher Raaen wrote: > > The list of NIST NTP servers is down for me, is anyone else seeing > > this? I'm getting a 404 error > > http://tf.nist.gov/tf-cgi/servers.cgi > > > > - -- > "No problem is so big or so complicated that it can't be run away > from!" -- Charles M. Schulz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJUUSEKAAoJEFKVLITDJSGSY8gP/jCGC2BT8oTmDLnxNVslL8wo > VF1gB4WZm7xzJZk4PW/MbAn06TRADZGlO7d80a4lSBEAWTiq913d1G0LeXiRCgn6 > o6dbgVjOgZWZ54J9jLwcSKaW6r0oXHO/DZ9PHKuZ0/t5A8I1YCiOQAD3fnBv2zmA > PZjcKfGo3kuDfmdrJTGRKvvIWQkGno150XUzLjpC6DYd46zx8MrqXnuZLRatdPr+ > pE/Z0moX35VUpC9y0pFrG9Pa2jjAIXRLbnDo6c8cp6noVGfQW+Xe8rX4+O7ddd27 > CatcjsGKpiGd6Z1MtXvID5JBINHqsmqOgSRLpj62xl7MvSFMEyjeEyRVol+sxOj5 > OBVObg4Pl4S7LrAJ1Bi9oK+CUW64E4jXpBfLejb+unv0jKF4RJSDec2ENskqkTb5 > Z/p4kjlFAd9aWq37HVYKbm2DcK/XR4kzra4IgQ+LI1MWfLpm+voKxFVzWP/OxAxq > ItYpQQ+tCtwAzQ245T7LvuWYXhIA/HiTct2DObEL6w/m2KPk8++zu0Zw5LZRWRAH > FPhsOWwd0fw0i4dlGBCFnMvHzLrqvB64pA7H8x/X+V+vyAdELUXwAYn0lrFfgoJc > WXZn99og5vqQnmv6r0ScGSoZER0lWpjaMIrkZoI8Pm5wS3fmjXpMhknlHqT8yPS/ > pGJ4SQoXrVv0dPy65cpo > =POmY > -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From rwebb at ropeguru.com Wed Oct 29 17:22:55 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 29 Oct 2014 13:22:55 -0400 Subject: NIST NTP Server List In-Reply-To: <5451210A.70401@actusa.net> References: <5451210A.70401@actusa.net> Message-ID: Try again. Just worked fine for me. On Wed, 29 Oct 2014 10:16:58 -0700 Stuart Sheldon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Yeah, it looks like it's down > > stu > > > > On 10/29/2014 10:14 AM, Brian Christopher Raaen wrote: >> The list of NIST NTP servers is down for me, is anyone else seeing >>this? >> I'm getting a 404 error >> http://tf.nist.gov/tf-cgi/servers.cgi >> > > - -- > "No problem is so big or so complicated that it can't be run away >from!" > -- Charles M. Schulz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJUUSEKAAoJEFKVLITDJSGSY8gP/jCGC2BT8oTmDLnxNVslL8wo > VF1gB4WZm7xzJZk4PW/MbAn06TRADZGlO7d80a4lSBEAWTiq913d1G0LeXiRCgn6 > o6dbgVjOgZWZ54J9jLwcSKaW6r0oXHO/DZ9PHKuZ0/t5A8I1YCiOQAD3fnBv2zmA > PZjcKfGo3kuDfmdrJTGRKvvIWQkGno150XUzLjpC6DYd46zx8MrqXnuZLRatdPr+ > pE/Z0moX35VUpC9y0pFrG9Pa2jjAIXRLbnDo6c8cp6noVGfQW+Xe8rX4+O7ddd27 > CatcjsGKpiGd6Z1MtXvID5JBINHqsmqOgSRLpj62xl7MvSFMEyjeEyRVol+sxOj5 > OBVObg4Pl4S7LrAJ1Bi9oK+CUW64E4jXpBfLejb+unv0jKF4RJSDec2ENskqkTb5 > Z/p4kjlFAd9aWq37HVYKbm2DcK/XR4kzra4IgQ+LI1MWfLpm+voKxFVzWP/OxAxq > ItYpQQ+tCtwAzQ245T7LvuWYXhIA/HiTct2DObEL6w/m2KPk8++zu0Zw5LZRWRAH >FPhsOWwd0fw0i4dlGBCFnMvHzLrqvB64pA7H8x/X+V+vyAdELUXwAYn0lrFfgoJc > WXZn99og5vqQnmv6r0ScGSoZER0lWpjaMIrkZoI8Pm5wS3fmjXpMhknlHqT8yPS/ > pGJ4SQoXrVv0dPy65cpo > =POmY > -----END PGP SIGNATURE----- From mailing-lists at brianraaen.com Wed Oct 29 17:26:14 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 29 Oct 2014 13:26:14 -0400 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: I'm still getting a 404. I am using a Windstream backbone, is this maybe path/server specific. Here is a dig. dig tf.nist.gov ; <<>> DiG 9.9.5-3-Ubuntu <<>> tf.nist.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46860 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tf.nist.gov. IN A ;; ANSWER SECTION: tf.nist.gov. 1784 IN CNAME tf.boulder.nist.gov. tf.boulder.nist.gov. 86384 IN CNAME ftp.boulder.nist.gov. ftp.boulder.nist.gov. 86384 IN A 132.163.4.45 ;; AUTHORITY SECTION: boulder.nist.gov. 1485 IN NS dns-y.boulder.nist.gov. boulder.nist.gov. 1485 IN NS gdnsea.nist.gov. ;; ADDITIONAL SECTION: dns-y.boulder.nist.gov. 1485 IN AAAA 2610:20:6b01:4::10 ;; Query time: 6 msec ;; SERVER: 68.70.255.9#53(68.70.255.9) ;; WHEN: Wed Oct 29 13:25:15 EDT 2014 ;; MSG SIZE rcvd: 168 On Wed, Oct 29, 2014 at 1:25 PM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: > I'm still getting a 404. I am using a Windstream backbone, is this maybe > path/server specific. Here is a dig. > > dig tf.nist.gov > > ; <<>> DiG 9.9.5-3-Ubuntu <<>> tf.nist.gov > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46860 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;tf.nist.gov. IN A > > ;; ANSWER SECTION: > tf.nist.gov. 1784 IN CNAME tf.boulder.nist.gov. > tf.boulder.nist.gov. 86384 IN CNAME ftp.boulder.nist.gov. > ftp.boulder.nist.gov. 86384 IN A 132.163.4.45 > > ;; AUTHORITY SECTION: > boulder.nist.gov. 1485 IN NS dns-y.boulder.nist.gov. > boulder.nist.gov. 1485 IN NS gdnsea.nist.gov. > > ;; ADDITIONAL SECTION: > dns-y.boulder.nist.gov. 1485 IN AAAA 2610:20:6b01:4::10 > > ;; Query time: 6 msec > ;; SERVER: 68.70.255.9#53(68.70.255.9) > ;; WHEN: Wed Oct 29 13:25:15 EDT 2014 > ;; MSG SIZE rcvd: 168 > > > > On Wed, Oct 29, 2014 at 1:22 PM, Chris Patsalou < > chrispatsalou at googlemail.com> wrote: > >> Appears up from here (London, UK) >> >> *NameIP AddressLocationStatusnist1-pa.ustiming.org >> 206.246.122.250Hatfield, PAAll services >> availabletime-a.nist.gov 129.6.15.28NIST, >> Gaithersburg, MarylandAll services busy, not recommendedtime-b.nist.gov >> 129.6.15.29NIST, Gaithersburg, MarylandAll services >> busy, not recommendedtime-c.nist.gov >> 129.6.15.30NIST, Gaithersburg, MarylandAll services >> availabletime-d.nist.gov 2610:20:6F15:15::27NIST, >> Gaithersburg, MarylandAll services via IPV6nist1-macon.macon.ga.us >> 98.175.203.200Macon, GeorgiaAll services >> availablewolfnisttime.com >> 207.223.123.18Birmingham, AlabamaAll services >> availablenist.time.nosc.us >> 96.226.242.9Carrollton, TexasAll services >> availablenist.expertsmi.com >> 50.245.103.198Monroe, Michigantemporary >> failurenist.netservicesgroup.com >> 64.113.32.5Southfield, MichiganAll >> services availablenisttime.carsoncity.k12.mi.us >> 66.219.116.140Carson City, >> MichiganAll services availablenist1-lnk.binary.net >> 216.229.0.179Lincoln, NebraskaAll services >> availablewwv.nist.gov 24.56.178.140WWV, Fort Collins, >> ColoradoAll services availabletime-a.timefreq.bldrdoc.gov >> 132.163.4.101NIST, Boulder, Coloradontp >> ok; time, daytime busytime-b.timefreq.bldrdoc.gov >> 132.163.4.102NIST, Boulder, ColoradoAll >> services busytime-c.timefreq.bldrdoc.gov >> 132.163.4.103NIST, Boulder, Coloradontp >> ok; time, daytime busytime.nist.gov global address >> for all serversMultiple locationsAll services availableutcnist.colorado.edu >> 128.138.140.44University of Colorado, >> BoulderAll services availableutcnist2.colorado.edu >> 128.138.141.172University of Colorado, >> BoulderAll services availablentp-nist.ldsbc.edu >> 198.60.73.8LDSBC, Salt Lake City, UtahAll >> services availablenist1-lv.ustiming.org >> 64.250.229.100Las Vegas, NevadaAll services >> availabletime-nw.nist.gov 131.107.13.100Microsoft, >> Redmond, WashingtonAll services very busynist-time-server.eoni.com >> 216.228.192.69La Grande, OregonAll >> services availableHope this helps?* >> >> On 29 October 2014 17:14, Brian Christopher Raaen < >> mailing-lists at brianraaen.com> wrote: >> >>> The list of NIST NTP servers is down for me, is anyone else seeing this? >>> I'm getting a 404 error >>> http://tf.nist.gov/tf-cgi/servers.cgi >>> >>> -- >>> Brian Christopher Raaen >>> Network Architect >>> Zcorum >>> >> >> > > > -- > Brian Christopher Raaen > Network Architect > Zcorum > -- Brian Christopher Raaen Network Architect Zcorum From rob at esecuredata.com Wed Oct 29 17:22:53 2014 From: rob at esecuredata.com (Robert Duffy) Date: Wed, 29 Oct 2014 10:22:53 -0700 Subject: NIST NTP Server List In-Reply-To: <5451210A.70401@actusa.net> References: <5451210A.70401@actusa.net> Message-ID: It's up from Vancouver, Canada. No 404 from here. On Wed, Oct 29, 2014 at 10:16 AM, Stuart Sheldon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Yeah, it looks like it's down > > stu > > > > On 10/29/2014 10:14 AM, Brian Christopher Raaen wrote: > > The list of NIST NTP servers is down for me, is anyone else seeing this? > > I'm getting a 404 error > > http://tf.nist.gov/tf-cgi/servers.cgi > > > > - -- > "No problem is so big or so complicated that it can't be run away from!" > -- Charles M. Schulz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJUUSEKAAoJEFKVLITDJSGSY8gP/jCGC2BT8oTmDLnxNVslL8wo > VF1gB4WZm7xzJZk4PW/MbAn06TRADZGlO7d80a4lSBEAWTiq913d1G0LeXiRCgn6 > o6dbgVjOgZWZ54J9jLwcSKaW6r0oXHO/DZ9PHKuZ0/t5A8I1YCiOQAD3fnBv2zmA > PZjcKfGo3kuDfmdrJTGRKvvIWQkGno150XUzLjpC6DYd46zx8MrqXnuZLRatdPr+ > pE/Z0moX35VUpC9y0pFrG9Pa2jjAIXRLbnDo6c8cp6noVGfQW+Xe8rX4+O7ddd27 > CatcjsGKpiGd6Z1MtXvID5JBINHqsmqOgSRLpj62xl7MvSFMEyjeEyRVol+sxOj5 > OBVObg4Pl4S7LrAJ1Bi9oK+CUW64E4jXpBfLejb+unv0jKF4RJSDec2ENskqkTb5 > Z/p4kjlFAd9aWq37HVYKbm2DcK/XR4kzra4IgQ+LI1MWfLpm+voKxFVzWP/OxAxq > ItYpQQ+tCtwAzQ245T7LvuWYXhIA/HiTct2DObEL6w/m2KPk8++zu0Zw5LZRWRAH > FPhsOWwd0fw0i4dlGBCFnMvHzLrqvB64pA7H8x/X+V+vyAdELUXwAYn0lrFfgoJc > WXZn99og5vqQnmv6r0ScGSoZER0lWpjaMIrkZoI8Pm5wS3fmjXpMhknlHqT8yPS/ > pGJ4SQoXrVv0dPy65cpo > =POmY > -----END PGP SIGNATURE----- > -- Regards, Rob ------------------------------------------------------------ -------------------- Robert Duffy eSecureData.com Inc. 1478 Hartley Ave. Coquitlam, BC V3K 7A1 T: (800) 620-1985 F: (800) 620-1986 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on the contents herein. Any communication received in error, or subsequent reply, should be deleted or destroyed. From techbb at gmail.com Wed Oct 29 17:31:49 2014 From: techbb at gmail.com (Brian Butler) Date: Wed, 29 Oct 2014 12:31:49 -0500 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: <54512485.60302@gmail.com> On 10/29/2014 12:14 PM, Brian Christopher Raaen wrote: > The list of NIST NTP servers is down for me, is anyone else seeing this? > I'm getting a 404 error > http://tf.nist.gov/tf-cgi/servers.cgi I concur, that URL results in 404 for me too. Much content which had been reliably available at http://tf.nist.gov and http://www.boulder.nist.gov/ seems to have vanished or broken lately. Not aware of alternate source. I prefer the NTP.org pools and other sources anyway, for reliability. I didn't memorize the federal time servers, but wasn't simply time.gov one of them? ~$ ntptrace time.gov 2610:20:6005:13::35: timed out, nothing received ***Request timed out http://www.time.gov/about.html leads to http://www.boulder.nist.gov/timefreq/ which redirects to the broken http://tf.nist.gov ... so this has got to be an error. Maybe they're doing some rearranging and moving, starting with the removing old part. At least tf.nist.gov is *up*, giving 403s and 404s. Keying in on .gov and ipv6 and related debacles, I wonder if results vary depending on whether one uses v4 or v6...idle speculation. Perhaps contact via http://www.nist.gov/public_affairs/contact.cfm (which, amusingly, came with a Foresee survey when I loaded it moments ago...) or timeinfo at boulder.nist.gov may yield something. From aftab.siddiqui at gmail.com Wed Oct 29 17:39:02 2014 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 29 Oct 2014 22:39:02 +0500 Subject: cidr-report In-Reply-To: References: Message-ID: > Has anyone noticed any issues resulting from the increase? > No > > http://www.cidr-report.org/as2.0/#General_Status > > But quite interestingly seems like something went wrong with AS13184 around 12:00 UTC. https://stat.ripe.net/AS13184#tabId=routing Regards, Aftab A. Siddiqui From jra at baylink.com Wed Oct 29 17:48:28 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 29 Oct 2014 13:48:28 -0400 (EDT) Subject: NIST NTP Server List In-Reply-To: <54512485.60302@gmail.com> Message-ID: <31267798.0.1414604908759.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Butler" > > I'm getting a 404 error > > http://tf.nist.gov/tf-cgi/servers.cgi Add me to the list of "it works" people. > I concur, that URL results in 404 for me too. Much content which had > been reliably available at http://tf.nist.gov and > http://www.boulder.nist.gov/ seems to have vanished or broken lately. > Not aware of alternate source. I prefer the NTP.org pools and other > sources anyway, for reliability. While boulder.nist does now seem to be a redirect, tf.nist and the child page are both working from Sprint LTE. > I didn't memorize the federal time servers, but wasn't simply time.gov > one of them? time.nist.gov is the round-robin. All this leads me to a pretty important question: What happens if Judah Levine gets hit by a bus? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From stb at lassitu.de Wed Oct 29 17:53:14 2014 From: stb at lassitu.de (Stefan Bethke) Date: Wed, 29 Oct 2014 18:53:14 +0100 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: > Am 29.10.2014 um 18:14 schrieb Brian Christopher Raaen : > > The list of NIST NTP servers is down for me, is anyone else seeing this? > I'm getting a 404 error > http://tf.nist.gov/tf-cgi/servers.cgi 404 from Kabel Deutschland reaching tf.nist.gov via AS1273, a small hoster in Hamburg, Germany via AS194, Inception Hosting (UK) via AS209; but proper page from VZ FIOS in Framingham, MA also via AS209. From AS13135, I get 404 on the web page, but my ntpd syncs to 128.138.141.172 just fine. Stefan -- Stefan Bethke Fon +49 151 14070811 From stb at lassitu.de Wed Oct 29 17:56:56 2014 From: stb at lassitu.de (Stefan Bethke) Date: Wed, 29 Oct 2014 18:56:56 +0100 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: Seems to be working over IPv4, not over IPv6. $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 404 Not Found

Not Found

$ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 NIST Internet Time Service > Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen : > > I'm still getting a 404. I am using a Windstream backbone, is this maybe > path/server specific. Here is a dig. > > dig tf.nist.gov -- Stefan Bethke Fon +49 151 14070811 From morrowc.lists at gmail.com Wed Oct 29 17:58:04 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 29 Oct 2014 10:58:04 -0700 Subject: cidr-report In-Reply-To: References: Message-ID: On Wed, Oct 29, 2014 at 10:39 AM, Aftab Siddiqui wrote: > AS13184 http://www.cidr-report.org/cgi-bin/as-report?as=AS13184&view=2.0 shows they deaggregated all of their aggregates and leaked that space to the world (mostly as /23 or /24 subnets of their larger prefixes) the ripestat link shows 2x 12.5k+ bounces in their prefix numbers. From mailing-lists at brianraaen.com Wed Oct 29 18:19:56 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 29 Oct 2014 14:19:56 -0400 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: That is interesting as the computer I am using is on dual-stack, and I am probably using IPv6 to reach it. On Wed, Oct 29, 2014 at 1:56 PM, Stefan Bethke wrote: > Seems to be working over IPv4, not over IPv6. > > $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 > > > 404 Not Found > >

Not Found

> $ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 > > > NIST Internet Time Service > content="text/html;charset=iso-8859-1"> > > > > > Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen < > mailing-lists at brianraaen.com>: > > > > I'm still getting a 404. I am using a Windstream backbone, is this maybe > > path/server specific. Here is a dig. > > > > dig tf.nist.gov > > -- > Stefan Bethke Fon +49 151 14070811 > > > > > -- Brian Christopher Raaen Network Architect Zcorum From dougb at dougbarton.us Wed Oct 29 18:23:47 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 29 Oct 2014 11:23:47 -0700 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: <545130B3.3030502@dougbarton.us> Also getting a 404 over IPv6. You can verify what transport we're using in Firefox using the SixorNot plugin. hth, Doug From morrowc.lists at gmail.com Wed Oct 29 18:30:02 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 29 Oct 2014 11:30:02 -0700 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: On Wed, Oct 29, 2014 at 11:19 AM, Brian Christopher Raaen wrote: > That is interesting as the computer I am using is on dual-stack, and I am > probably using IPv6 to reach it. > "happy eyeballs" > On Wed, Oct 29, 2014 at 1:56 PM, Stefan Bethke wrote: > >> Seems to be working over IPv4, not over IPv6. >> >> $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >> >> >> 404 Not Found >> >>

Not Found

>> $ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >> >> >> NIST Internet Time Service >> > content="text/html;charset=iso-8859-1"> >> >> >> >> > Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen < >> mailing-lists at brianraaen.com>: >> > >> > I'm still getting a 404. I am using a Windstream backbone, is this maybe >> > path/server specific. Here is a dig. >> > >> > dig tf.nist.gov >> >> -- >> Stefan Bethke Fon +49 151 14070811 >> >> >> >> >> > > > -- > Brian Christopher Raaen > Network Architect > Zcorum From dougb at dougbarton.us Wed Oct 29 18:36:37 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 29 Oct 2014 11:36:37 -0700 Subject: NIST NTP Server List In-Reply-To: References: Message-ID: <545133B5.1020109@dougbarton.us> Happy Eyeballs has nothing to do with it. This is a server misconfiguration plain and simple. Doug On 10/29/14 11:30 AM, Christopher Morrow wrote: > On Wed, Oct 29, 2014 at 11:19 AM, Brian Christopher Raaen > wrote: >> That is interesting as the computer I am using is on dual-stack, and I am >> probably using IPv6 to reach it. >> > > "happy eyeballs" > >> On Wed, Oct 29, 2014 at 1:56 PM, Stefan Bethke wrote: >> >>> Seems to be working over IPv4, not over IPv6. >>> >>> $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >>> >>> >>> 404 Not Found >>> >>>

Not Found

>>> $ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >>> >>> >>> NIST Internet Time Service >>> >> content="text/html;charset=iso-8859-1"> >>> >>> >>> >>>> Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen < >>> mailing-lists at brianraaen.com>: >>>> >>>> I'm still getting a 404. I am using a Windstream backbone, is this maybe >>>> path/server specific. Here is a dig. >>>> >>>> dig tf.nist.gov >>> >>> -- >>> Stefan Bethke Fon +49 151 14070811 >>> >>> >>> >>> >>> >> >> >> -- >> Brian Christopher Raaen >> Network Architect >> Zcorum From morrowc.lists at gmail.com Wed Oct 29 19:36:10 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 29 Oct 2014 12:36:10 -0700 Subject: NIST NTP Server List In-Reply-To: <545133B5.1020109@dougbarton.us> References: <545133B5.1020109@dougbarton.us> Message-ID: On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton wrote: > Happy Eyeballs has nothing to do with it. This is a server misconfiguration > plain and simple. > I meant that it seems that v4 is broken, but v6 is not. so sure, it's a server thing, but he's seeing different results maybe as a side effect of eyeballs. > Doug > > > > On 10/29/14 11:30 AM, Christopher Morrow wrote: >> >> On Wed, Oct 29, 2014 at 11:19 AM, Brian Christopher Raaen >> wrote: >>> >>> That is interesting as the computer I am using is on dual-stack, and I am >>> probably using IPv6 to reach it. >>> >> >> "happy eyeballs" >> >>> On Wed, Oct 29, 2014 at 1:56 PM, Stefan Bethke wrote: >>> >>>> Seems to be working over IPv4, not over IPv6. >>>> >>>> $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >>>> >>>> >>>> 404 Not Found >>>> >>>>

Not Found

>>>> $ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 >>>> >>>> >>>> NIST Internet Time Service >>>> >>> content="text/html;charset=iso-8859-1"> >>>> >>>> >>>> >>>>> Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen < >>>> >>>> mailing-lists at brianraaen.com>: >>>>> >>>>> >>>>> I'm still getting a 404. I am using a Windstream backbone, is this >>>>> maybe >>>>> path/server specific. Here is a dig. >>>>> >>>>> dig tf.nist.gov >>>> >>>> >>>> -- >>>> Stefan Bethke Fon +49 151 14070811 >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Brian Christopher Raaen >>> Network Architect >>> Zcorum > > From mailing-lists at brianraaen.com Wed Oct 29 19:55:21 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 29 Oct 2014 15:55:21 -0400 Subject: NIST NTP Server List In-Reply-To: References: <545133B5.1020109@dougbarton.us> Message-ID: I disabled IPv6 on my machine and was able to pull it up, reenable IPv6 and I start getting 404's. On Wed, Oct 29, 2014 at 3:36 PM, Christopher Morrow wrote: > On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton wrote: > > Happy Eyeballs has nothing to do with it. This is a server > misconfiguration > > plain and simple. > > > > I meant that it seems that v4 is broken, but v6 is not. > so sure, it's a server thing, but he's seeing different results maybe > as a side effect of eyeballs. > > > Doug > > > > > > > > On 10/29/14 11:30 AM, Christopher Morrow wrote: > >> > >> On Wed, Oct 29, 2014 at 11:19 AM, Brian Christopher Raaen > >> wrote: > >>> > >>> That is interesting as the computer I am using is on dual-stack, and I > am > >>> probably using IPv6 to reach it. > >>> > >> > >> "happy eyeballs" > >> > >>> On Wed, Oct 29, 2014 at 1:56 PM, Stefan Bethke wrote: > >>> > >>>> Seems to be working over IPv4, not over IPv6. > >>>> > >>>> $ curl -6 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 > >>>> > >>>> > >>>> 404 Not Found > >>>> > >>>>

Not Found

> >>>> $ curl -4 http://tf.nist.gov/tf-cgi/servers.cgi 2>/dev/null | head -5 > >>>> > >>>> > >>>> NIST Internet Time Service > >>>> >>>> content="text/html;charset=iso-8859-1"> > >>>> > >>>> > >>>> > >>>>> Am 29.10.2014 um 18:26 schrieb Brian Christopher Raaen < > >>>> > >>>> mailing-lists at brianraaen.com>: > >>>>> > >>>>> > >>>>> I'm still getting a 404. I am using a Windstream backbone, is this > >>>>> maybe > >>>>> path/server specific. Here is a dig. > >>>>> > >>>>> dig tf.nist.gov > >>>> > >>>> > >>>> -- > >>>> Stefan Bethke Fon +49 151 14070811 > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Brian Christopher Raaen > >>> Network Architect > >>> Zcorum > > > > > -- Brian Christopher Raaen Network Architect Zcorum From dougb at dougbarton.us Wed Oct 29 20:05:55 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 29 Oct 2014 13:05:55 -0700 Subject: NIST NTP Server List In-Reply-To: References: <545133B5.1020109@dougbarton.us> Message-ID: <545148A3.1000806@dougbarton.us> On 10/29/14 12:36 PM, Christopher Morrow wrote: > On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton wrote: >> Happy Eyeballs has nothing to do with it. This is a server misconfiguration >> plain and simple. >> > > I meant that it seems that v4 is broken, but v6 is not. Other way around. From ekgermann at cctec.com Wed Oct 29 20:05:21 2014 From: ekgermann at cctec.com (Eric Germann) Date: Wed, 29 Oct 2014 16:05:21 -0400 Subject: Seeking VPS providers for low volume network probe Message-ID: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Greetings, I'm looking for recommendations on a reliable VPS Provider(s) who can provide 1. Centos 6 2. IPv4 and IPv6 (preferably) physically in the regions of African Continent, Eastern Europe/Russia, Middle East, South America and Canada. I've already deployed some globally with Vultr and Amazon (Brazil region). Basically doing a low volume test point probe (512MB-1GB RAM, < 20GB disk) for latency measurements. Would prefer to have a secure (logically and financially) and reliable host. Thanks in advance, EKG From josh at imaginenetworksllc.com Wed Oct 29 21:11:46 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 29 Oct 2014 17:11:46 -0400 Subject: Seeking VPS providers for low volume network probe In-Reply-To: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> References: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Message-ID: Ramnode is like $24 a year. They have a Netherlands cluster. I'm running CentOS6 and get both IPv4 and v6. They use OpenVZ for the really cheap stuff so depending on what you're doing you may run into issues. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Oct 29, 2014 at 4:05 PM, Eric Germann wrote: > > > Greetings, > > I'm looking for recommendations on a reliable VPS Provider(s) who can > provide > > 1. Centos 6 > 2. IPv4 and IPv6 (preferably) > > physically in the regions of African Continent, Eastern Europe/Russia, > Middle East, South America and Canada. > > I've already deployed some globally with Vultr and Amazon (Brazil > region). > > Basically doing a low volume test point probe (512MB-1GB RAM, < 20GB > disk) for latency measurements. Would prefer to have a secure (logically > and financially) and reliable host. > > Thanks in advance, > > EKG > > > From marka at isc.org Wed Oct 29 21:19:26 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 30 Oct 2014 08:19:26 +1100 Subject: .mil postmaster Contacts? In-Reply-To: Your message of "Wed, 29 Oct 2014 08:00:34 -0700." <20141029150034.GA25731@esri.com> References: <20141027175207.GA15830@esri.com> <023c01cff24a$f4d97f30$de8c7d90$@gmail.com> <5450E81F.6040104@pubnix.net> <014e01cff386$b7f57dc0$27e07940$@gmail.com> <20141029150034.GA25731@esri.com> Message-ID: <20141029211927.2F59E22B6C86@rock.dv.isc.org> Well the servers for DISA.MIL are not EDNS compliant, they drop EDNS version 1 queries and unless you are running a experimental nameserver which expects EDNS version negotiation to work it shouldn't be causing you issues yet. Otherwise the lookups of the MX records succeed. There is no good reason to block EDNS version 1 queries. All it does is break EDNS version negotiation. Mark In message <20141029150034.GA25731 at esri.com>, Ray Van Dolson writes: > On Wed, Oct 29, 2014 at 10:43:34AM -0400, Chuck Church wrote: > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alain Hebert > > Sent: Wednesday, October 29, 2014 9:14 AM > > To: nanog at nanog.org > > Subject: Re: .mil postmaster Contacts? > > > > > Might be related to the news (CNN this morning) about the WH network bein > g > > exploited for a few days now. > > > They might be going after some .mil to and the tightening up of those > > networks may cause disruption. > > > > > > I think it has to do with DNSSEC. The google DNS FAQ mentions (along with > > someone else who emailed me off-list) checking DNSVIZ for issues. So > > looking at: > > http://dnsviz.net/d/disa.mil/dnssec/ > > > > seems to indicate some issues. RRSET TTL MISMATCH I think they all are. > > Any DISA people on here? Using a non-Google DNS (which I guess isn't doing > > DNSSEC validation) does resolve the names fine. > > > > Chuck > > I saw the same errors in dnsviz, but was unsure if they were sufficient > to cause lookup failures (they were "warnings" only). > > # dig @8.8.8.8 disa.mil MX +dnssec > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 disa.mil MX + > dnssec > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9111 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;disa.mil. IN MX > > ;; ANSWER SECTION: > disa.mil. 20039 IN MX 5 indal.disa.mil. > disa.mil. 20039 IN MX 0 pico.disa.mil. > disa.mil. 20039 IN MX 10 dnipro.disa.mil. > disa.mil. 20039 IN RRSIG MX 8 2 86400 20141121222228 2 > 0141022222228 40608 disa.mil. lC2W9knYgviYJUKMYw9FJueUk4cR19spu7QsX3novmYrlOI > 70F0Rrzxm adU17tvfq1vbtzgYH0FriGIMdywPu/ssO7mK4KGhDj7pkQCcJZzlbrMe OlJOcC9mQc > jgb6nt5KREBaIGzTGY0gA7AM6X2Ft/t9ZdsE/K+jNejgEc 4+M= > > I see the "ad" flag in the query response flags, so am thinking this > lookup succeeded and was validated? > > I do note that once we disabled DNSSEC on our resolvers we were able to > push mail out to these domains. May have been coincidental -- needs > further testing. > > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ktokash at hotmail.com Wed Oct 29 22:24:46 2014 From: ktokash at hotmail.com (keith tokash) Date: Wed, 29 Oct 2014 15:24:46 -0700 Subject: Industry standard bandwidth guarantee? Message-ID: Hi *, sorry if this has been answered, I did look. Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? Specifically I'm thinking of a sub-interface on a shared physical interface. I've not thought much about it but if there's a more generally-accepted guideline than, "when the customers start leaving / when you leave," I'm at least 5% ears. Thanks, Keith From jimpop at gmail.com Wed Oct 29 22:41:55 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 29 Oct 2014 18:41:55 -0400 Subject: Seeking VPS providers for low volume network probe In-Reply-To: References: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Message-ID: On Wed, Oct 29, 2014 at 5:11 PM, Josh Luthman wrote: > Ramnode is like $24 a year. They have a Netherlands cluster. I'm running > CentOS6 and get both IPv4 and v6. They use OpenVZ for the really cheap > stuff so depending on what you're doing you may run into issues. +1 for RamNode (AS3842). I have several VPS'es from them, very very stable, awesome Support. Other nods go to OneAsiaHost (AS24482) in Singapore, and RansomIT (AS45177) down under. All three of those providers fundamentally understand BGP/peering. As for Africa... I use the RamNode Netherlands to provide coverage to Africa. I spent the past year and half trolling the African VPS marketplace, and while there are excellent providers, the peering SUCKS. I'm not going to get into why the peering sucks... let's just say that one or two strategic providers seem to like for everything to route through London. Anyhoo... In South Africa you can get solid VPS'es from domains.co.za, and vps.co.za. Their network peerings will also allow you to adequately cover 75% of Nambia, Botswana, Zambia, Zimbabwe, Lesotho, Swaziland, and Mozambique. On the Eastern side of the continent there is kilihost.com (formerly aptus.co.tz), however they are still working with TIX and KIXP (and have been for years) to establish better regional peering (the whole of East Africa seems to route 95% of traffic through London... someone on this list provides that transit.... hopefully at cost....). Western Africa is best reached/served from London/Netherlands... however there are a few Nigerian VPS hosts but the infrastructure is not on par with the South African or London datacenters. No VPSes in Riyadh, Dubai, or Mumbai, seemed to have any capabilities of providing better connectivity to East Africa. Why do I know all this, well ~2 years ago there was a thread here about how geoip DNS sucks (or such) and I set out to build a hobby geoip CDN to see just how much it sucked. My takeaway is that the tech is there, the politics (peering) isn't.... and that is most prevalent in the whole of Africa (and pretty much unique to Africa). -Jim P. From Valdis.Kletnieks at vt.edu Wed Oct 29 23:02:53 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 29 Oct 2014 19:02:53 -0400 Subject: Industry standard bandwidth guarantee? In-Reply-To: Your message of "Wed, 29 Oct 2014 15:24:46 -0700." References: Message-ID: <27952.1414623773@turing-police.cc.vt.edu> On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said: > Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? How are you going to come up with a standard that covers both the uplink from Billy-Bob's Bait, Fish, Tackle, and Wifi, where a fractional gigabit may be plenty, and the size pipes that got clogged in the recent Netflix network neutrality kerfluffle? And where your PoPs are (and how many) matters as well - if you have a peering agreement with another carrier, and you exchange 35Gbits/sec of traffic, the bandwidth at each peer point will depend on whether you peer at one location, or 5, or 7, or 15..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ktokash at hotmail.com Wed Oct 29 23:57:13 2014 From: ktokash at hotmail.com (keith tokash) Date: Wed, 29 Oct 2014 16:57:13 -0700 Subject: Industry standard bandwidth guarantee? In-Reply-To: <27952.1414623773@turing-police.cc.vt.edu> References: , <27952.1414623773@turing-police.cc.vt.edu> Message-ID: I'm sorry I should have been more specific. I'm referring to the *percentage* of a circuit's bandwidth. For example if you order a 20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15% off, which sounds hefty, but I'm not sure what's realistic to expect. And beyond expectations, I'm wondering if there's a threshold that industry movers/shakers generally yell at their vendor for going below, and try to get a refund or move the link to a new port/box. > To: ktokash at hotmail.com > Subject: Re: Industry standard bandwidth guarantee? > From: Valdis.Kletnieks at vt.edu > Date: Wed, 29 Oct 2014 19:02:53 -0400 > CC: nanog at nanog.org > > On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said: > > > Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? > > How are you going to come up with a standard that covers both the uplink from > Billy-Bob's Bait, Fish, Tackle, and Wifi, where a fractional gigabit may be > plenty, and the size pipes that got clogged in the recent Netflix network > neutrality kerfluffle? > > And where your PoPs are (and how many) matters as well - if you have a peering > agreement with another carrier, and you exchange 35Gbits/sec of traffic, the > bandwidth at each peer point will depend on whether you peer at one location, > or 5, or 7, or 15..... > From rafael at gav.ufsc.br Thu Oct 30 00:13:59 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 29 Oct 2014 19:13:59 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: I'd say if there's a strong financial reasoning (or greed some times) behind a complaint, it will be brought up, otherwise shouldn't it be all based on civil talks and agreements anyway? On Wed, Oct 29, 2014 at 6:57 PM, keith tokash wrote: > I'm sorry I should have been more specific. I'm referring to the > *percentage* of a circuit's bandwidth. For example if you order a 20Mb > site to site circuit and iperf shows 17Mb. Well ... that's 15% off, which > sounds hefty, but I'm not sure what's realistic to expect. > > And beyond expectations, I'm wondering if there's a threshold that > industry movers/shakers generally yell at their vendor for going below, and > try to get a refund or move the link to a new port/box. > > > > > > To: ktokash at hotmail.com > > Subject: Re: Industry standard bandwidth guarantee? > > From: Valdis.Kletnieks at vt.edu > > Date: Wed, 29 Oct 2014 19:02:53 -0400 > > CC: nanog at nanog.org > > > > On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said: > > > > > Is there an industry standard regarding how much bandwidth an > inter-carrier circuit should guarantee? > > > > How are you going to come up with a standard that covers both the uplink > from > > Billy-Bob's Bait, Fish, Tackle, and Wifi, where a fractional gigabit may > be > > plenty, and the size pipes that got clogged in the recent Netflix network > > neutrality kerfluffle? > > > > And where your PoPs are (and how many) matters as well - if you have a > peering > > agreement with another carrier, and you exchange 35Gbits/sec of traffic, > the > > bandwidth at each peer point will depend on whether you peer at one > location, > > or 5, or 7, or 15..... > > > > From bensjoberg at gmail.com Thu Oct 30 00:04:33 2014 From: bensjoberg at gmail.com (Ben Sjoberg) Date: Wed, 29 Oct 2014 19:04:33 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: That 3Mb difference is probably just packet overhead + congestion control. Goodput on a single TCP flow is always less than link bandwidth, regardless of the link. On Wed, Oct 29, 2014 at 6:57 PM, keith tokash wrote: > I'm sorry I should have been more specific. I'm referring to the *percentage* of a circuit's bandwidth. For example if you order a 20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15% off, which sounds hefty, but I'm not sure what's realistic to expect. > > And beyond expectations, I'm wondering if there's a threshold that industry movers/shakers generally yell at their vendor for going below, and try to get a refund or move the link to a new port/box. > > > > >> To: ktokash at hotmail.com >> Subject: Re: Industry standard bandwidth guarantee? >> From: Valdis.Kletnieks at vt.edu >> Date: Wed, 29 Oct 2014 19:02:53 -0400 >> CC: nanog at nanog.org >> >> On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said: >> >> > Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? >> >> How are you going to come up with a standard that covers both the uplink from >> Billy-Bob's Bait, Fish, Tackle, and Wifi, where a fractional gigabit may be >> plenty, and the size pipes that got clogged in the recent Netflix network >> neutrality kerfluffle? >> >> And where your PoPs are (and how many) matters as well - if you have a peering >> agreement with another carrier, and you exchange 35Gbits/sec of traffic, the >> bandwidth at each peer point will depend on whether you peer at one location, >> or 5, or 7, or 15..... >> > From matthew at walster.org Thu Oct 30 05:26:35 2014 From: matthew at walster.org (Matthew Walster) Date: Thu, 30 Oct 2014 13:26:35 +0800 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: On 30 October 2014 08:04, Ben Sjoberg wrote: > That 3Mb difference is probably just packet overhead + congestion > control. Goodput on a single TCP flow is always less than link > bandwidth, regardless of the link. ​I've always found it useful to refer to this: https://www.gronkulator.com/overhead.html M ​ From mark.tinka at seacom.mu Thu Oct 30 05:35:40 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 30 Oct 2014 07:35:40 +0200 Subject: Seeking VPS providers for low volume network probe In-Reply-To: References: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Message-ID: <201410300735.40903.mark.tinka@seacom.mu> On Thursday, October 30, 2014 12:41:55 AM Jim Popovitch wrote: > As for Africa... I use the RamNode Netherlands to provide > coverage to Africa. I spent the past year and half > trolling the African VPS marketplace, and while there > are excellent providers, the peering SUCKS. I'm not > going to get into why the peering sucks... let's just > say that one or two strategic providers seem to like for > everything to route through London. Anyhoo... In South > Africa you can get solid VPS'es from domains.co.za, and > vps.co.za. Their network peerings will also allow you > to adequately cover 75% of Nambia, Botswana, Zambia, > Zimbabwe, Lesotho, Swaziland, and Mozambique. On the > Eastern side of the continent there is kilihost.com > (formerly aptus.co.tz), however they are still working > with TIX and KIXP (and have been for years) to establish > better regional peering (the whole of East Africa seems > to route 95% of traffic through London... someone on > this list provides that transit.... hopefully at > cost....). For eastern and southern Africa, there are reasonable peering locations that could help fix these problems. But the issue is not that a handful of providers prefer to route everything through London, but that the majority of service providers and mobile networks in Africa prefer to buy capacity into Europe, than from local service providers selling IP in Africa. The reasons for this are legacy. While those reasons are falling away and we are seeing more and more uptake for service in-continent, it's not coming fast enough. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From carlos at race.com Thu Oct 30 07:04:48 2014 From: carlos at race.com (Carlos Alcantar) Date: Thu, 30 Oct 2014 07:04:48 +0000 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: Message-ID: For access side (home users) we have slightly over provisioned there circuits, to minimize the "I¹m paying for 20 why am I getting 19" type of calls. Provision them out to 25 they get 23-24 on there speedtest everyone is happy. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 10/29/14, 3:24 PM, "keith tokash" wrote: >Hi *, sorry if this has been answered, I did look. > >Is there an industry standard regarding how much bandwidth an >inter-carrier circuit should guarantee? Specifically I'm thinking of a >sub-interface on a shared physical interface. I've not thought much >about it but if there's a more generally-accepted guideline than, "when >the customers start leaving / when you leave," I'm at least 5% ears. > >Thanks, >Keith > From karsten.elfenbein at gmail.com Thu Oct 30 07:58:54 2014 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Thu, 30 Oct 2014 08:58:54 +0100 Subject: Seeking VPS providers for low volume network probe In-Reply-To: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> References: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Message-ID: Hi, did you have a look at https://atlas.ripe.net/ ? They have two types of probes that are already in place. Best regards Karsten 2014-10-29 21:05 GMT+01:00 Eric Germann : > > > Greetings, > > I'm looking for recommendations on a reliable VPS Provider(s) who can > provide > > 1. Centos 6 > 2. IPv4 and IPv6 (preferably) > > physically in the regions of African Continent, Eastern Europe/Russia, > Middle East, South America and Canada. > > I've already deployed some globally with Vultr and Amazon (Brazil > region). > > Basically doing a low volume test point probe (512MB-1GB RAM, < 20GB > disk) for latency measurements. Would prefer to have a secure (logically > and financially) and reliable host. > > Thanks in advance, > > EKG > > From streiner at cluebyfour.org Thu Oct 30 11:33:39 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 30 Oct 2014 07:33:39 -0400 (EDT) Subject: Industry standard bandwidth guarantee? In-Reply-To: <27952.1414623773@turing-police.cc.vt.edu> References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: On Wed, 29 Oct 2014, Valdis.Kletnieks at vt.edu wrote: > On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said: > >> Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? > > And where your PoPs are (and how many) matters as well - if you have a peering > agreement with another carrier, and you exchange 35Gbits/sec of traffic, the > bandwidth at each peer point will depend on whether you peer at one location, > or 5, or 7, or 15..... ...and many different carriers have different definitions of "congestion". Some carriers might have several definitions of the word, depending on the service you have and which group you happen to be speaking to that day. It's pretty much impossible to guarantee bandwidth on an inter-carrier packet-switched link. jms From mysidia at gmail.com Thu Oct 30 12:23:44 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 30 Oct 2014 07:23:44 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote: > That 3Mb difference is probably just packet overhead + congestion Yes... however, that's actually an industry standard of implying higher performance than reality, because end users don't care about the datagram overhead which their applications do not see they just want X megabits of real-world performance, and this industry would perhaps be better off if we called a link that can deliver at best 17 Megabits of Goodput reliably a "15 Megabit goodput +5 service" instead of calling it a "20 Megabit service" Or at least appended a disclaimer *"Real-world best case download performance: approximately 1.8 Megabytes per second" Subtracting overhead and quoting that instead of raw link speeds. But that's not the industry standard. I believe the industry standard is to provide the numerically highest performance number as is possible through best-case theoretical testing; let the end user experience disappointment and explain the misunderstanding later. End users also more concerned about their individual download rate on actual file transfers and not the total averaged aggregate throughput of the network of 10 users or 10 streams downloading data simultaneously, or characteristics transport protocols are concerned about such as fairness. > control. Goodput on a single TCP flow is always less than link > bandwidth, regardless of the link. --- -JH From fourzerofour at gmail.com Thu Oct 30 13:42:03 2014 From: fourzerofour at gmail.com (Justin) Date: Thu, 30 Oct 2014 09:42:03 -0400 Subject: Seeking VPS providers for low volume network probe In-Reply-To: References: <0ea2d3afbdca050b4ec4db2e0a9b9722@imap.semperen.com> Message-ID: I've used several off this list https://www.exoticvps.com/ On Thu, Oct 30, 2014 at 3:58 AM, Karsten Elfenbein < karsten.elfenbein at gmail.com> wrote: > Hi, > > did you have a look at https://atlas.ripe.net/ ? > They have two types of probes that are already in place. > > > Best regards > Karsten > > 2014-10-29 21:05 GMT+01:00 Eric Germann : > > > > > > Greetings, > > > > I'm looking for recommendations on a reliable VPS Provider(s) who can > > provide > > > > 1. Centos 6 > > 2. IPv4 and IPv6 (preferably) > > > > physically in the regions of African Continent, Eastern Europe/Russia, > > Middle East, South America and Canada. > > > > I've already deployed some globally with Vultr and Amazon (Brazil > > region). > > > > Basically doing a low volume test point probe (512MB-1GB RAM, < 20GB > > disk) for latency measurements. Would prefer to have a secure (logically > > and financially) and reliable host. > > > > Thanks in advance, > > > > EKG > > > > > From mailing-lists at brianraaen.com Thu Oct 30 14:09:40 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Thu, 30 Oct 2014 10:09:40 -0400 Subject: NIST NTP Server List In-Reply-To: <545148A3.1000806@dougbarton.us> References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> Message-ID: Still acting up for me this morning. On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton wrote: > On 10/29/14 12:36 PM, Christopher Morrow wrote: > >> On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton >> wrote: >> >>> Happy Eyeballs has nothing to do with it. This is a server >>> misconfiguration >>> plain and simple. >>> >>> >> I meant that it seems that v4 is broken, but v6 is not. >> > > Other way around. > > -- Brian Christopher Raaen Network Architect Zcorum From mailing-lists at brianraaen.com Thu Oct 30 17:17:55 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Thu, 30 Oct 2014 13:17:55 -0400 Subject: NIST NTP Server List In-Reply-To: References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> Message-ID: It is now working over IPv6 On Thu, Oct 30, 2014 at 10:09 AM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: > Still acting up for me this morning. > > On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton wrote: > >> On 10/29/14 12:36 PM, Christopher Morrow wrote: >> >>> On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton >>> wrote: >>> >>>> Happy Eyeballs has nothing to do with it. This is a server >>>> misconfiguration >>>> plain and simple. >>>> >>>> >>> I meant that it seems that v4 is broken, but v6 is not. >>> >> >> Other way around. >> >> > > > -- > Brian Christopher Raaen > Network Architect > Zcorum > -- Brian Christopher Raaen Network Architect Zcorum From bmah at kitchenlab.org Thu Oct 30 17:20:12 2014 From: bmah at kitchenlab.org (Bruce A. Mah) Date: Thu, 30 Oct 2014 10:20:12 -0700 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: , <27952.1414623773@turing-police.cc.vt.edu> Message-ID: <5452734C.1040008@kitchenlab.org> If memory serves me right, keith tokash wrote: > I'm sorry I should have been more specific. I'm referring to the > *percentage* of a circuit's bandwidth. For example if you order a > 20Mb site to site circuit and iperf shows 17Mb. Well ... that's 15% > off, which sounds hefty, but I'm not sure what's realistic to expect. This doesn't exactly answer your original question, but... iperf (as well as its follow-on, iperf3) runs between two end hosts, so an iperf test will be measuring other effects, such as congestion (as others have pointed out), but also end-host tuning, the LANs to which the end hosts are attached, etc. ${WORK} maintains a good reference to tuning networks for high-performance R&E networks...some of these techniques are applicable to other environments as well. http://fasterdata.es.net/ Bruce. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From blair.trosper at gmail.com Thu Oct 30 18:06:26 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 30 Oct 2014 13:06:26 -0500 Subject: AWS Contact Message-ID: Could someone from AWS contact me off-list. From dorian at blackrose.org Thu Oct 30 18:21:00 2014 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 30 Oct 2014 14:21:00 -0400 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: > On Oct 30, 2014, at 8:23 AM, Jimmy Hess wrote: > > On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote: > >> That 3Mb difference is probably just packet overhead + congestion > > Yes... however, that's actually an industry standard of implying > higher performance than reality, because end users don't care about > the datagram overhead which their applications do not see they just > want X megabits of real-world performance, and this industry would > perhaps be better off if we called a link that can deliver at best 17 > Megabits of Goodput reliably a "15 Megabit goodput +5 service" > instead of calling it a "20 Megabit service" > > Or at least appended a disclaimer *"Real-world best case download > performance: approximately 1.8 Megabytes per second" > > > Subtracting overhead and quoting that instead of raw link speeds. > But that's not the industry standard. I believe the industry standard > is to provide the numerically highest performance number as is > possible through best-case theoretical testing; let the end user > experience disappointment and explain the misunderstanding later. > > End users also more concerned about their individual download rate on > actual file transfers and not the total averaged aggregate > throughput of the network of 10 users or 10 streams downloading data > simultaneously, or characteristics transport protocols are > concerned about such as fairness. Not it’s not. All the link speeds are products of standards, be it SDH/SONET, PDH, or various flavors of ethernet. They are objective numbers. What you are advocating, given that much of the overhead is per packet/frame overhead and will vary based on the application and packet size distribution, will create more confusion than what we have today. -dorian From rafael at gav.ufsc.br Thu Oct 30 18:21:41 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 30 Oct 2014 13:21:41 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: You can't just ignore protocol overhead (or any system's overhead). If an application requires X bits per second of actual payload, then your system should be designed properly and take into account overhead, as well as failure rates, peak utilization hours, etc. This is valid for networking, automobile production, etc etc.. On Thu, Oct 30, 2014 at 7:23 AM, Jimmy Hess wrote: > On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote: > > > That 3Mb difference is probably just packet overhead + congestion > > Yes... however, that's actually an industry standard of implying > higher performance than reality, because end users don't care about > the datagram overhead which their applications do not see they just > want X megabits of real-world performance, and this industry would > perhaps be better off if we called a link that can deliver at best 17 > Megabits of Goodput reliably a "15 Megabit goodput +5 service" > instead of calling it a "20 Megabit service" > > Or at least appended a disclaimer *"Real-world best case download > performance: approximately 1.8 Megabytes per second" > > > Subtracting overhead and quoting that instead of raw link speeds. > But that's not the industry standard. I believe the industry standard > is to provide the numerically highest performance number as is > possible through best-case theoretical testing; let the end user > experience disappointment and explain the misunderstanding later. > > End users also more concerned about their individual download rate on > actual file transfers and not the total averaged aggregate > throughput of the network of 10 users or 10 streams downloading data > simultaneously, or characteristics transport protocols are > concerned about such as fairness. > > > > control. Goodput on a single TCP flow is always less than link > > bandwidth, regardless of the link. > > --- > -JH > From sander at steffann.nl Thu Oct 30 19:11:53 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 30 Oct 2014 20:11:53 +0100 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu> Message-ID: Hi, > and this industry would > perhaps be better off if we called a link that can deliver at best 17 > Megabits of Goodput reliably a "15 Megabit goodput +5 service" > instead of calling it a "20 Megabit service" But you don't know what the user is going to do over the link. If the average packet size is very small the overhead will be much larger. And the path-MTU depends on many factors besides the customer link. The only real number to give to the customer is the raw link speed. Everything else depends on how the link is used. Giving customer numbers like "IF you do X then expect a maximum speed of Y" will only cause more confusion. Especially because you can only give theoretical maximums because real speeds depend on many other factors (pMTU, RTT, congestion somewhere etc) as well. Cheers, Sander From ktokash at hotmail.com Thu Oct 30 19:44:43 2014 From: ktokash at hotmail.com (keith tokash) Date: Thu, 30 Oct 2014 12:44:43 -0700 Subject: Industry standard bandwidth guarantee? In-Reply-To: References: <27952.1414623773@turing-police.cc.vt.edu>, , , Message-ID: I'm willing to recommend to sales people that they advertise the size of the *usable* tube as well as the tube overall, but I'm fairly sure they won't care. Ben rightly stated the order of operations: BS quote > disappointment > mea culpa/level setting. If that fails I'll at least make sure no one quotes circuit sizes in terms of "movies transferred," or whatever metric is popular at the moment. >From that nice gronkulator page I see a couple of MPLS and a dot1q tag bringing a theoretical limit down to around 94% (non-jumbos), which to my conservatively estimating mind means customers should expect ~90 on a normal day. This isn't factoring latency, intermittent loss, or congestion elsewhere on the tubes, so I'm not sure where this has gotten me. A number has been specified to be sure, but one that blows away with a gentle sneeze. From: rafael at gav.ufsc.br Date: Thu, 30 Oct 2014 13:21:41 -0500 Subject: Re: Industry standard bandwidth guarantee? To: mysidia at gmail.com CC: bensjoberg at gmail.com; ktokash at hotmail.com; nanog at nanog.org You can't just ignore protocol overhead (or any system's overhead). If an application requires X bits per second of actual payload, then your system should be designed properly and take into account overhead, as well as failure rates, peak utilization hours, etc. This is valid for networking, automobile production, etc etc.. On Thu, Oct 30, 2014 at 7:23 AM, Jimmy Hess wrote: On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg wrote: > That 3Mb difference is probably just packet overhead + congestion Yes... however, that's actually an industry standard of implying higher performance than reality, because end users don't care about the datagram overhead which their applications do not see they just want X megabits of real-world performance, and this industry would perhaps be better off if we called a link that can deliver at best 17 Megabits of Goodput reliably a "15 Megabit goodput +5 service" instead of calling it a "20 Megabit service" Or at least appended a disclaimer *"Real-world best case download performance: approximately 1.8 Megabytes per second" Subtracting overhead and quoting that instead of raw link speeds. But that's not the industry standard. I believe the industry standard is to provide the numerically highest performance number as is possible through best-case theoretical testing; let the end user experience disappointment and explain the misunderstanding later. End users also more concerned about their individual download rate on actual file transfers and not the total averaged aggregate throughput of the network of 10 users or 10 streams downloading data simultaneously, or characteristics transport protocols are concerned about such as fairness. > control. Goodput on a single TCP flow is always less than link > bandwidth, regardless of the link. --- -JH From jgreco at ns.sol.net Thu Oct 30 19:53:52 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 30 Oct 2014 14:53:52 -0500 (CDT) Subject: Industry standard bandwidth guarantee? In-Reply-To: Message-ID: <201410301953.s9UJrrU2061954@aurora.sol.net> > You can't just ignore protocol overhead (or any system's overhead). If an > application requires X bits per second of actual payload, then your system > should be designed properly and take into account overhead, as well as > failure rates, peak utilization hours, etc. This is valid for networking, > automobile production, etc etc.. Are you saying that the service provider should take into account overhead? And report the amount of bandwidth available for payload? Even there we have some wiggle room, but at least it is something the customer will be able to work out (IP header overhead, etc). If not, I'm at a bit of a loss. As a customer, how do I identify that my traffic is actually going over an ATM-over-MPLS-over-VPN-over-whatever- other-bitrobbing-tech circuit and that I should only expect to see 60% of the speed advertised? ... 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 marka at isc.org Thu Oct 30 21:09:23 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 31 Oct 2014 08:09:23 +1100 Subject: Industry standard bandwidth guarantee? In-Reply-To: Your message of "Thu, 30 Oct 2014 12:44:43 -0700." References: <27952.1414623773@turing-police.cc.vt.edu>, , , Message-ID: <20141030210923.C1B9222D658B@rock.dv.isc.org> Useable data over a link depends on packet size. 56 byte IP packets at X Mbps 1500 byte IP packets at Y Mbps This is then comparable across link technologies and framings used on those technologies. You can then compare a DSL vs GPON vs Cable as provided by the ISP using Apples to Apples comparisons. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From javier at advancedmachines.us Thu Oct 30 22:04:09 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 30 Oct 2014 18:04:09 -0400 Subject: NIST NTP Server List In-Reply-To: References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> Message-ID: Either is alcatel-lucent.com for the past 2 days I noticed. Ipv6 version of their site broken. On Oct 30, 2014 1:18 PM, "Brian Christopher Raaen" < mailing-lists at brianraaen.com> wrote: > It is now working over IPv6 > > On Thu, Oct 30, 2014 at 10:09 AM, Brian Christopher Raaen < > mailing-lists at brianraaen.com> wrote: > > > Still acting up for me this morning. > > > > On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton > wrote: > > > >> On 10/29/14 12:36 PM, Christopher Morrow wrote: > >> > >>> On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton > >>> wrote: > >>> > >>>> Happy Eyeballs has nothing to do with it. This is a server > >>>> misconfiguration > >>>> plain and simple. > >>>> > >>>> > >>> I meant that it seems that v4 is broken, but v6 is not. > >>> > >> > >> Other way around. > >> > >> > > > > > > -- > > Brian Christopher Raaen > > Network Architect > > Zcorum > > > > > > -- > Brian Christopher Raaen > Network Architect > Zcorum > From marka at isc.org Thu Oct 30 22:27:50 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 31 Oct 2014 09:27:50 +1100 Subject: NIST NTP Server List In-Reply-To: Your message of "Thu, 30 Oct 2014 18:04:09 -0400." References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> Message-ID: <20141030222750.8DF4622D7586@rock.dv.isc.org> IPv6 is production. Report the problem. In message , Javier J writes: > Either is alcatel-lucent.com for the past 2 days I noticed. Ipv6 version of > their site broken. > On Oct 30, 2014 1:18 PM, "Brian Christopher Raaen" < > mailing-lists at brianraaen.com> wrote: > > > It is now working over IPv6 > > > > On Thu, Oct 30, 2014 at 10:09 AM, Brian Christopher Raaen < > > mailing-lists at brianraaen.com> wrote: > > > > > Still acting up for me this morning. > > > > > > On Wed, Oct 29, 2014 at 4:05 PM, Doug Barton > > wrote: > > > > > >> On 10/29/14 12:36 PM, Christopher Morrow wrote: > > >> > > >>> On Wed, Oct 29, 2014 at 11:36 AM, Doug Barton > > >>> wrote: > > >>> > > >>>> Happy Eyeballs has nothing to do with it. This is a server > > >>>> misconfiguration > > >>>> plain and simple. > > >>>> > > >>>> > > >>> I meant that it seems that v4 is broken, but v6 is not. > > >>> > > >> > > >> Other way around. > > >> > > >> > > > > > > > > > -- > > > Brian Christopher Raaen > > > Network Architect > > > Zcorum > > > > > > > > > > > -- > > Brian Christopher Raaen > > Network Architect > > Zcorum > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From pete at altadena.net Fri Oct 31 00:01:10 2014 From: pete at altadena.net (Pete Carah) Date: Thu, 30 Oct 2014 20:01:10 -0400 Subject: NIST NTP Server List In-Reply-To: <20141030222750.8DF4622D7586@rock.dv.isc.org> References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> <20141030222750.8DF4622D7586@rock.dv.isc.org> Message-ID: <5452D146.4080307@altadena.net> On 10/30/2014 06:27 PM, Mark Andrews wrote: > IPv6 is production. Report the problem. > Sorry for reporting it here, but there seems to be more than one problem (the link resulting from clicking on "nist time". I get the nist front page fine on v6, then click on the time link and get a 404 looking for a strange url: "hxxp://time.gov/HTML5" (which could be fine but does look a little strange.) -- Pete From marka at isc.org Fri Oct 31 00:21:36 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 31 Oct 2014 11:21:36 +1100 Subject: NIST NTP Server List In-Reply-To: Your message of "Thu, 30 Oct 2014 20:01:10 -0400." <5452D146.4080307@altadena.net> References: <545133B5.1020109@dougbarton.us> <545148A3.1000806@dougbarton.us> <20141030222750.8DF4622D7586@rock.dv.isc.org> <5452D146.4080307@altadena.net> Message-ID: <20141031002137.004B122DA704@rock.dv.isc.org> In message <5452D146.4080307 at altadena.net>, Pete Carah writes: > On 10/30/2014 06:27 PM, Mark Andrews wrote: > > IPv6 is production. Report the problem. > > > Sorry for reporting it here, but there seems to be more than one problem > (the link resulting from clicking on "nist time". What does reporting a 404 to nanog do? The network to them is UP. Since the front page is up and actually has a address for reporting web problems I would expect that you would report the problem there (I've cc'd the address). If the front page wasn't up you should do a whois lookup and use those contact details except this a .gov domain where whois is a farce. So you also need to contact your federal representative and complain about that. Nist can put contact details on their web page: Public Inquiries Unit NIST, 100 Bureau Drive, Stop 1070, Gaithersburg, MD 20899-1070 Email: inquiries at nist.gov Phone: (301) 975-NIST (6478) or Federal Relay Service (800) 877-8339 (TTY) But the whois give this farcical response: % DOTGOV WHOIS Server ready Domain Name: NIST.GOV Status: ACTIVE >>> Last update of whois database: 2014-10-31T00:16:27Z <<< Please be advised that this whois server only contains information pertaining to the .GOV domain. For information for other domains please use the whois server at RS.INTERNIC.NET. > I get the nist front page fine on v6, then click on the time link and > get a 404 looking for a strange url: > "hxxp://time.gov/HTML5" (which could be fine but does look a little > strange.) > > -- Pete > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rafael at gav.ufsc.br Fri Oct 31 02:38:51 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 30 Oct 2014 21:38:51 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: <201410301953.s9UJrrU2061954@aurora.sol.net> References: <201410301953.s9UJrrU2061954@aurora.sol.net> Message-ID: Yes, and no. If you are a given a limited resource (in this case, a physical port that can process no more than 1gbps for example) and your efficiency in transferring data over that port is not 100%, the provider itself is not to blame. Each and every protocol has limitations, and in this case we are talking about payload I guess. What the provider should say is: if you need "true" 20mbps, then instead you should contract 20mbps X 1+your-payload-process-loss. A silly example would be this: you fill your gas tank with 12 gallons... After driving until it's empty, your engine only used an average of 6 gallons to actually move you from point A to point B. The other 6 were just wasted in form of heat. Do you ask for your money back at the gas station? Or maybe you invest in a hybrid car? Like I mentioned before, this is not unique to networking, it's a broader concern in the design of any system or process. On Thu, Oct 30, 2014 at 2:53 PM, Joe Greco wrote: > > You can't just ignore protocol overhead (or any system's overhead). If an > > application requires X bits per second of actual payload, then your > system > > should be designed properly and take into account overhead, as well as > > failure rates, peak utilization hours, etc. This is valid for networking, > > automobile production, etc etc.. > > > Are you saying that the service provider should take into account overhead? > And report the amount of bandwidth available for payload? Even there we > have some wiggle room, but at least it is something the customer will be > able to work out (IP header overhead, etc). > > If not, I'm at a bit of a loss. As a customer, how do I identify that my > traffic is actually going over an ATM-over-MPLS-over-VPN-over-whatever- > other-bitrobbing-tech circuit and that I should only expect to see 60% of > the speed advertised? > > ... 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 jgreco at ns.sol.net Fri Oct 31 11:02:28 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 31 Oct 2014 06:02:28 -0500 (CDT) Subject: Industry standard bandwidth guarantee? In-Reply-To: Message-ID: <201410311102.s9VB2STR074846@aurora.sol.net> > Yes, and no. > > If you are a given a limited resource (in this case, a physical port that > can process no more than 1gbps for example) and your efficiency in > transferring data over that port is not 100%, the provider itself is not to > blame. Each and every protocol has limitations, and in this case we are > talking about payload I guess. What the provider should say is: if you need > "true" 20mbps, then instead you should contract 20mbps X > 1+your-payload-process-loss. That's fine as long as they're giving you a resource that can potentially transfer the 20Mbps. > A silly example would be this: you fill your gas tank with 12 gallons... > After driving until it's empty, your engine only used an average of 6 > gallons to actually move you from point A to point B. The other 6 were just > wasted in form of heat. Do you ask for your money back at the gas station? > Or maybe you invest in a hybrid car? That *is* a silly example. A more proper analogy would be that you buy 12 gallons of gas, but the station only deposits 11 gallons in your tank because the pumps are operated by gasoline engines and they feel it is fine to count the number of gallons pulled out of their tank instead of the amount given to the customer. > Like I mentioned before, this is not unique to networking, it's a broader > concern in the design of any system or process. Finding new ways to give the customer less while making it look like more has a long, proud history, yes. ... 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 david at mailplus.nl Fri Oct 31 11:21:12 2014 From: david at mailplus.nl (David Hofstee) Date: Fri, 31 Oct 2014 12:21:12 +0100 Subject: Industry standard bandwidth guarantee? In-Reply-To: <201410311102.s9VB2STR074846@aurora.sol.net> References: <201410311102.s9VB2STR074846@aurora.sol.net> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75CAC0683D@SBS1.blinker.local> -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Joe Greco Verzonden: Friday, October 31, 2014 12:02 PM Aan: Rafael Possamai CC: keith tokash; nanog at nanog.org Onderwerp: Re: Industry standard bandwidth guarantee? ... >> A silly example would be this: you fill your gas tank with 12 gallons... >> After driving until it's empty, your engine only used an average of 6 >> gallons to actually move you from point A to point B. The other 6 were >> just wasted in form of heat. Do you ask for your money back at the gas station? >> Or maybe you invest in a hybrid car? > >That *is* a silly example. > >A more proper analogy would be that you buy 12 gallons of gas, but the station only deposits 11 gallons in your tank because the >pumps are operated by gasoline engines and they feel it is fine to count the number of gallons pulled out of their tank instead of the amount given to the customer. And bits/s is exactly what you get. With your example: You don't get kilometers at the gas stations, you get quantities of gas (e.g. a liter). And depending on a lot of factors, you get a distance from that quantity. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) From lear at cisco.com Fri Oct 31 15:50:36 2014 From: lear at cisco.com (Eliot Lear) Date: Fri, 31 Oct 2014 16:50:36 +0100 Subject: looking for clueful mail administrator at Google Message-ID: <5453AFCC.9080206@cisco.com> Please contact me offline about a misbehaving filter. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 486 bytes Desc: OpenPGP digital signature URL: From jlsorrels at kanren.net Fri Oct 31 16:14:18 2014 From: jlsorrels at kanren.net (Jeff Sorrels) Date: Fri, 31 Oct 2014 11:14:18 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: <201410311102.s9VB2STR074846@aurora.sol.net> References: <201410311102.s9VB2STR074846@aurora.sol.net> Message-ID: <5453B55A.2040505@kanren.net> And if you look at it from the provider's prospective, they have lots of customers who want 12 gallons of gas worth of driving time, but only want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it showed their purchased gas only gave them 10 gallons worth of driving time). Consider a better analogy from the provider side: A customer bakes a nice beautiful fruit cake for their Aunt Eddie in wilds of Saskatchewan. The cake is 10 kg - but they want to make sure it gets to Eddie properly, so they wrap it in foil, then bubble wrap, then put it in a box. They have this 10kg cake and 1kg of packaging to get it to up north. They then go to the ISP store to get it delivered - and are surprised, that to get it there, they have to pay to ship 11kg. But the cake is only 10kg! If they pay to ship 11kg for a 10kg cake, obviously the ISP is trying to screw them. The ISP should deliver the 10kg cake at the 10kg rate and eat the cost of the rest - no matter how many kg the packaging is or how much space they actually have on the delivery truck. And then the customer goes to the Internet to decry the nerve of the ISP for not explaining the concept of "packaging" up front and in big letters. "Why they should tell you - to ship 10kg, buy 11kg up front! Or better yet, they shouldn't calculate the box when weighing for shipping! I should pay for the contents and the wrapping, no matter how much it is, shouldn't even be considered! It's plain robbery. Harrumph". Jeff On 10/31/2014 6:02 AM, Joe Greco wrote: > That's fine as long as they're giving you a resource that can potentially > transfer the 20Mbps. > > That *is* a silly example. > > A more proper analogy would be that you buy 12 gallons of gas, but the > station only deposits 11 gallons in your tank because the pumps are > operated by gasoline engines and they feel it is fine to count the > number of gallons pulled out of their tank instead of the amount given > to the customer. > > > Finding new ways to give the customer less while making it look like more > has a long, proud history, yes. > > ... JG -- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels at kanren.net 785-856-9820, #2 From rj.bacon at verizon.com Fri Oct 31 16:49:43 2014 From: rj.bacon at verizon.com (Bacon, Ricky (RJ)) Date: Fri, 31 Oct 2014 12:49:43 -0400 Subject: Industry standard bandwidth guarantee? In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75CAC0683D@SBS1.blinker.local> References: <201410311102.s9VB2STR074846@aurora.sol.net> <78C35D6C1A82D243B830523B4193CF5F75CAC0683D@SBS1.blinker.local> Message-ID: <2B7669201D58CD4C8A2150DB12B129CF165714E6D3@FHDP1LUMXC7V43.us.one.verizon.com> >That *is* a silly example. > >A more proper analogy would be that you buy 12 gallons of gas, but the >station only deposits 11 gallons in your tank because the pumps are operated by gasoline engines and they feel it is fine to count the number of gallons pulled out of their tank instead of the amount given to the customer. So if you tell a customer you are giving them 10 g of space for their email, you shouldn't charge them for the storage taken up by each individual email's headers. Is that how it works though? Not so much I think. As long as the pricing policy is consistent across the industry, and it is, then you are not being ripped off. Creating, implementing and maintaining a deep dive billing systems to figure out how much of your traffic is packet header and protocol and how much is your data would just add to operating expense which would eventually be passed on to the customer. If you want a pipe that will let you transmit 10G of raw data, I can have than implemented. Just tell me where to connect the two ends. If you want to connect one end to our router or switch, we'll do that too, but it won't get you much. If you want to participate on the internet with a 10Gig link, you are going to have to use protocols, and the data will have to be in layer 3 packets, and they can be any kind you choose. But you are originating the request packets and receiving the reply packets and those will include overhead. We just transport them to and from the internet. In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download limitation in bits per second. You will not exceed that unless you run multiple sessions, and even then it will always be less than link speed, which is your physical limit, how many bits you can receive in a second, protocol or otherwise. From laszlo at heliacal.net Fri Oct 31 16:56:35 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 31 Oct 2014 16:56:35 -0000 Subject: Industry standard bandwidth guarantee? In-Reply-To: <5453B55A.2040505@kanren.net> References: <201410311102.s9VB2STR074846@aurora.sol.net> <5453B55A.2040505@kanren.net> Message-ID: <00d801cff52b$a2c0d8e0$e8428aa0$@heliacal.net> If you're selling to end users, under promise and over deliver. Tell them 20Mbit but provision for 25. That way when they run their speedtest, they're delighted that they're getting more, instead of being disappointed and feeling screwed. In practice they will leave it idle most of the time anyway. This isn't a technical problem, it's just a matter of setting expectations and satisfying them. Some of the customers might be completely clueless, but if your goal is to make them happy, then explaining protocol overhead is probably not the right way. -Laszlo -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeff Sorrels Sent: Friday, October 31, 2014 16:14 To: nanog at nanog.org Subject: Re: Industry standard bandwidth guarantee? And if you look at it from the provider's prospective, they have lots of customers who want 12 gallons of gas worth of driving time, but only want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it showed their purchased gas only gave them 10 gallons worth of driving time). Consider a better analogy from the provider side: A customer bakes a nice beautiful fruit cake for their Aunt Eddie in wilds of Saskatchewan. The cake is 10 kg - but they want to make sure it gets to Eddie properly, so they wrap it in foil, then bubble wrap, then put it in a box. They have this 10kg cake and 1kg of packaging to get it to up north. They then go to the ISP store to get it delivered - and are surprised, that to get it there, they have to pay to ship 11kg. But the cake is only 10kg! If they pay to ship 11kg for a 10kg cake, obviously the ISP is trying to screw them. The ISP should deliver the 10kg cake at the 10kg rate and eat the cost of the rest - no matter how many kg the packaging is or how much space they actually have on the delivery truck. And then the customer goes to the Internet to decry the nerve of the ISP for not explaining the concept of "packaging" up front and in big letters. "Why they should tell you - to ship 10kg, buy 11kg up front! Or better yet, they shouldn't calculate the box when weighing for shipping! I should pay for the contents and the wrapping, no matter how much it is, shouldn't even be considered! It's plain robbery. Harrumph". Jeff On 10/31/2014 6:02 AM, Joe Greco wrote: > That's fine as long as they're giving you a resource that can potentially > transfer the 20Mbps. > > That *is* a silly example. > > A more proper analogy would be that you buy 12 gallons of gas, but the > station only deposits 11 gallons in your tank because the pumps are > operated by gasoline engines and they feel it is fine to count the > number of gallons pulled out of their tank instead of the amount given > to the customer. > > > Finding new ways to give the customer less while making it look like more > has a long, proud history, yes. > > ... JG -- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels at kanren.net 785-856-9820, #2 From tim.h at bendtel.com Fri Oct 31 17:34:23 2014 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 31 Oct 2014 10:34:23 -0700 Subject: Is it unusual to remove defunct rr objects? Message-ID: <20141031103423.615e1aea@cool.bendtel.com> In the recent past, we've had another provider in our same market erroneously advertising prefixes for some of our customers. After we got it cleared up, I noticed that there were some old route objects in RADB that were entered for that provider years ago by 360. These route objects, in a sense, legitimized, the erroneous advertisements by matching the prefixes to that providers ASN. As that provider no longer uses 360/Zayo, I asked Zayo if they could remove the objects. Once the request made it to someone who understood what I was asking, they spent some time and effort over the next few weeks (much appreciated by me, I might add) in hunting down the info they needed to (I assume) manage the old 360 maintnr object. They then removed the offending objects (again, my thanks). One of the Zayo support folks mentioned to me, somewhat apologetically, that it took some time as nobody had ever made such a request before. So this got me wondering: is it really such a rare thing to manage ones route objects such that old defunct data is removed? I'm not under the impression that the issue I had would have been alleviated any by the related route objects having been removed beforehand, but their existence wasn't helping me any either. I've since found a disturbing number of defunct objects that relate to my customers (and me) in a similar way, and I have mostly had success in getting them cleared up. If my relatively small customer base is any indication, there are more incorrect objects out there than correct ones. I feel this is something I should have been looking into sooner. Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts? Sorry that this turned out so long; I wanted to give some context. --TimH From jared at puck.Nether.net Fri Oct 31 17:39:34 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 31 Oct 2014 13:39:34 -0400 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: <20141031103423.615e1aea@cool.bendtel.com> References: <20141031103423.615e1aea@cool.bendtel.com> Message-ID: <20141031173933.GA26681@puck.nether.net> On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote: > I've since found a disturbing number of defunct objects that > relate to my customers (and me) in a similar way, and I have mostly > had success in getting them cleared up. If my relatively small > customer base is any indication, there are more incorrect objects out > there than correct ones. I feel this is something I should have been > looking into sooner. People tend to treat things like IRR (eg: RADB, etc) as a garbage pit you toss things into and never remove from. > Is this a non-issue that I shouldn't worry about? Doesn't the > quality of this data effect Origin Validation efforts? Yes it does. This has a fairly severe impact for those that build off the IRR data for filters. We have seen customers end up including AS7018 in their AS-SET or as you noticed have other legacy routes appear. > > Sorry that this turned out so long; I wanted to give some > context. No worries. I've got a transient routing leak detector that does find/fuzz these issues which has been running for a few years now. I'm guessing you may see some of the related prefixes there as a result. It's in need of a U/I redesign (code welcome) but is located here: http://puck.nether.net/bgp/leakinfo.cgi - 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 cscora at apnic.net Fri Oct 31 18:11:12 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Nov 2014 04:11:12 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201410311811.s9VIBCm7005456@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, TRNOG, 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 01 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 518662 Prefixes after maximum aggregation: 199550 Deaggregation factor: 2.60 Unique aggregates announced to Internet: 253190 Total ASes present in the Internet Routing Table: 48444 Prefixes per ASN: 10.71 Origin-only ASes present in the Internet Routing Table: 36294 Origin ASes announcing only one prefix: 16343 Transit ASes present in the Internet Routing Table: 6178 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 93 Max AS path prepend of ASN ( 55644) 86 Prefixes from unregistered ASNs in the Routing Table: 1809 Unregistered ASNs in the Routing Table: 435 Number of 32-bit ASNs allocated by the RIRs: 7781 Number of 32-bit ASNs visible in the Routing Table: 5972 Prefixes from 32-bit ASNs in the Routing Table: 21275 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 351 Number of addresses announced to Internet: 2713052580 Equivalent to 161 /8s, 181 /16s and 229 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176879 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 128935 Total APNIC prefixes after maximum aggregation: 36851 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 133024 Unique aggregates announced from the APNIC address blocks: 53376 APNIC Region origin ASes present in the Internet Routing Table: 4988 APNIC Prefixes per ASN: 26.67 APNIC Region origin ASes announcing only one prefix: 1199 APNIC Region transit ASes present in the Internet Routing Table: 862 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 93 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1153 Number of APNIC addresses announced to Internet: 736685408 Equivalent to 43 /8s, 232 /16s and 237 /24s Percentage of available APNIC address space announced: 86.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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, 150/8, 153/8, 163/8, 171/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: 171887 Total ARIN prefixes after maximum aggregation: 85320 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173718 Unique aggregates announced from the ARIN address blocks: 81425 ARIN Region origin ASes present in the Internet Routing Table: 16390 ARIN Prefixes per ASN: 10.60 ARIN Region origin ASes announcing only one prefix: 6093 ARIN Region transit ASes present in the Internet Routing Table: 1696 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 246 Number of ARIN addresses announced to Internet: 1053210304 Equivalent to 62 /8s, 198 /16s and 182 /24s Percentage of available ARIN address space announced: 55.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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125642 Total RIPE prefixes after maximum aggregation: 63681 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 131109 Unique aggregates announced from the RIPE address blocks: 82697 RIPE Region origin ASes present in the Internet Routing Table: 17797 RIPE Prefixes per ASN: 7.37 RIPE Region origin ASes announcing only one prefix: 8186 RIPE Region transit ASes present in the Internet Routing Table: 2910 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 39 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3155 Number of RIPE addresses announced to Internet: 691574916 Equivalent to 41 /8s, 56 /16s and 152 /24s Percentage of available RIPE address space announced: 100.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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58688 Total LACNIC prefixes after maximum aggregation: 10780 LACNIC Deaggregation factor: 5.44 Prefixes being announced from the LACNIC address blocks: 67517 Unique aggregates announced from the LACNIC address blocks: 30600 LACNIC Region origin ASes present in the Internet Routing Table: 2365 LACNIC Prefixes per ASN: 28.55 LACNIC Region origin ASes announcing only one prefix: 654 LACNIC Region transit ASes present in the Internet Routing Table: 470 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1359 Number of LACNIC addresses announced to Internet: 168363520 Equivalent to 10 /8s, 9 /16s and 6 /24s Percentage of available LACNIC address space announced: 100.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12122 Total AfriNIC prefixes after maximum aggregation: 2874 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 12943 Unique aggregates announced from the AfriNIC address blocks: 4774 AfriNIC Region origin ASes present in the Internet Routing Table: 733 AfriNIC Prefixes per ASN: 17.66 AfriNIC Region origin ASes announcing only one prefix: 211 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 59 Number of AfriNIC addresses announced to Internet: 59790848 Equivalent to 3 /8s, 144 /16s and 86 /24s Percentage of available AfriNIC address space announced: 59.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2950 11584 926 Korea Telecom 17974 2824 903 77 PT Telekomunikasi Indonesia 7545 2431 336 124 TPG Telecom Limited 4755 1922 412 189 TATA Communications formerly 9829 1671 1322 37 National Internet Backbone 4812 1520 2098 109 China Telecom (Group) 9808 1475 6639 15 Guangdong Mobile Communicatio 4808 1424 2211 423 CNCGROUP IP network China169 9583 1360 111 559 Sify Limited 9498 1312 333 94 BHARTI Airtel Ltd. 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 2894 3688 51 BellSouth.net Inc. 22773 2844 2940 143 Cox Communications Inc. 18566 2045 379 184 MegaPath Corporation 7029 1975 1959 313 Windstream Communications Inc 20115 1815 1794 477 Charter Communications 4323 1633 1052 408 tw telecom holdings, inc. 6983 1542 867 250 ITC^Deltacom 30036 1487 309 611 Mediacom Communications Corp 701 1426 11266 710 MCI Communications Services, 22561 1321 409 247 CenturyTel Internet Holdings, 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 1840 297 352 TELLCOM ILETISIM HIZMETLERI A 20940 1502 581 1108 Akamai International B.V. 8402 1387 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1037 100 29 TOV "Bank-Inform" 8551 956 373 43 Bezeq International-Ltd 6849 829 356 26 JSC "Ukrtelecom" 6830 782 2339 435 Liberty Global Operations B.V 9198 776 346 30 JSC Kazakhtelecom 12479 757 785 96 France Telecom Espana SA 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 3035 494 238 Telmex Colombia S.A. 28573 2580 2317 107 NET Servi�os de Comunica��o S 6147 1779 374 30 Telefonica del Peru S.A.A. 7303 1765 1171 241 Telecom Argentina S.A. 8151 1481 3017 432 Uninet S.A. de C.V. 6503 1158 434 59 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 27947 915 130 51 Telconet S.A 26615 899 2325 35 Tim Celular S.A. 3816 893 384 146 COLOMBIA TELECOMUNICACIONES S 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 1390 958 13 TE-AS 24863 957 280 26 Link Egypt (Link.NET) 6713 678 760 38 Office National des Postes et 36992 328 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 232 19 6 Data Telecom Service 37457 182 161 6 Telkom SA Ltd. 36947 177 807 13 Telecom Algeria 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 10620 3035 494 238 Telmex Colombia S.A. 4766 2950 11584 926 Korea Telecom 6389 2894 3688 51 BellSouth.net Inc. 22773 2844 2940 143 Cox Communications Inc. 17974 2824 903 77 PT Telekomunikasi Indonesia 28573 2580 2317 107 NET Servi�os de Comunica��o S 7545 2431 336 124 TPG Telecom Limited 18566 2045 379 184 MegaPath Corporation 7029 1975 1959 313 Windstream Communications Inc 4755 1922 412 189 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2894 2843 BellSouth.net Inc. 17974 2824 2747 PT Telekomunikasi Indonesia 22773 2844 2701 Cox Communications Inc. 28573 2580 2473 NET Servi�os de Comunica��o S 7545 2431 2307 TPG Telecom Limited 4766 2950 2024 Korea Telecom 18566 2045 1861 MegaPath Corporation 6147 1779 1749 Telefonica del Peru S.A.A. 4755 1922 1733 TATA Communications formerly 7029 1975 1662 Windstream 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:12 /10:31 /11:90 /12:262 /13:501 /14:1011 /15:1715 /16:13046 /17:7209 /18:11942 /19:25102 /20:35370 /21:37390 /22:55368 /23:48597 /24:278052 /25:1107 /26:1065 /27:717 /28:15 /29:19 /30:11 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2065 2844 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1674 2894 BellSouth.net Inc. 6147 1345 1779 Telefonica del Peru S.A.A. 30036 1334 1487 Mediacom Communications Corp 6983 1228 1542 ITC^Deltacom 7029 1195 1975 Windstream Communications Inc 34984 1160 1840 TELLCOM ILETISIM HIZMETLERI A 11492 1135 1185 CABLE ONE, INC. 8402 1072 1387 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1342 2:679 3:3 4:17 5:1185 6:21 8:772 12:1848 13:5 14:1181 15:17 16:2 17:42 18:21 20:50 23:949 24:1765 27:1811 31:1339 32:41 33:2 34:5 36:156 37:1814 38:1008 39:14 40:234 41:2957 42:339 43:580 44:20 45:81 46:2066 47:28 49:746 50:807 52:12 54:57 55:4 56:8 57:32 58:1143 59:643 60:435 61:1755 62:1250 63:1837 64:4413 65:2277 66:4182 67:2040 68:1093 69:3270 70:875 71:486 72:1985 74:2613 75:373 76:409 77:1613 78:980 79:765 80:1327 81:1285 82:800 83:658 84:716 85:1359 86:429 87:1188 88:503 89:1808 90:138 91:5809 92:798 93:1642 94:1940 95:1291 96:426 97:340 98:1097 99:48 100:67 101:743 103:5989 104:498 105:155 106:181 107:653 108:596 109:1982 110:1049 111:1421 112:729 113:913 114:795 115:1225 116:1183 117:1013 118:1547 119:1384 120:746 121:970 122:2209 123:1692 124:1474 125:1534 128:622 129:387 130:369 131:925 132:413 133:165 134:323 135:82 136:324 137:318 138:383 139:201 140:228 141:420 142:601 143:444 144:514 145:111 146:672 147:560 148:1045 149:409 150:512 151:640 152:475 153:241 154:402 155:621 156:382 157:322 158:278 159:923 160:330 161:603 162:1810 163:368 164:644 165:671 166:363 167:690 168:1127 169:119 170:1427 171:191 172:60 173:1640 174:710 175:611 176:1539 177:3700 178:2090 179:804 180:1799 181:1792 182:1689 183:702 184:709 185:2283 186:2972 187:1689 188:2040 189:1531 190:7920 191:765 192:7742 193:5556 194:4062 195:3620 196:1641 197:776 198:5303 199:5474 200:6492 201:2915 202:9162 203:9043 204:4694 205:2668 206:3102 207:2983 208:3921 209:3764 210:3328 211:1852 212:2434 213:2188 214:850 215:84 216:5619 217:1701 218:673 219:390 220:1379 221:825 222:568 223:696 End of report From rafael at gav.ufsc.br Fri Oct 31 18:28:24 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 31 Oct 2014 13:28:24 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: <00d801cff52b$a2c0d8e0$e8428aa0$@heliacal.net> References: <201410311102.s9VB2STR074846@aurora.sol.net> <5453B55A.2040505@kanren.net> <00d801cff52b$a2c0d8e0$e8428aa0$@heliacal.net> Message-ID: I have a feeling this issue only occurs with residential customers, and perhaps small businesses. It is most likely cheaper to over deliver in this case then to maintain a larger call center and support team to attempt to explain end users how TCP has limitations. No two large communication businesses (ISP in this case) with properly educated technical people (i.e. network engineers or similar) on both ends should start an argument on who gets to cover transmission overhead (or for simplicity, the packaging on the cake). On Fri, Oct 31, 2014 at 11:56 AM, Laszlo Hanyecz wrote: > If you're selling to end users, under promise and over deliver. Tell them > 20Mbit but provision for 25. That way when they run their speedtest, > they're delighted that they're getting more, instead of being disappointed > and feeling screwed. In practice they will leave it idle most of the time > anyway. > This isn't a technical problem, it's just a matter of setting expectations > and satisfying them. Some of the customers might be completely clueless, > but if your goal is to make them happy, then explaining protocol overhead > is > probably not the right way. > > -Laszlo > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeff Sorrels > Sent: Friday, October 31, 2014 16:14 > To: nanog at nanog.org > Subject: Re: Industry standard bandwidth guarantee? > > And if you look at it from the provider's prospective, they have lots of > customers who want 12 gallons of gas worth of driving time, but only > want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it > showed their purchased gas only gave them 10 gallons worth of driving > time). > > Consider a better analogy from the provider side: A customer bakes a > nice beautiful fruit cake for their Aunt Eddie in wilds of > Saskatchewan. The cake is 10 kg - but they want to make sure it gets > to Eddie properly, so they wrap it in foil, then bubble wrap, then put > it in a box. They have this 10kg cake and 1kg of packaging to get it to > up north. They then go to the ISP store to get it delivered - and are > surprised, that to get it there, they have to pay to ship 11kg. But the > cake is only 10kg! If they pay to ship 11kg for a 10kg cake, obviously > the ISP is trying to screw them. The ISP should deliver the 10kg cake at > the 10kg rate and eat the cost of the rest - no matter how many kg the > packaging is or how much space they actually have on the delivery truck. > > And then the customer goes to the Internet to decry the nerve of the ISP > for not explaining the concept of "packaging" up front and in big > letters. "Why they should tell you - to ship 10kg, buy 11kg up front! > Or better yet, they shouldn't calculate the box when weighing for > shipping! I should pay for the contents and the wrapping, no matter how > much it is, shouldn't even be considered! It's plain robbery. Harrumph". > > Jeff > > On 10/31/2014 6:02 AM, Joe Greco wrote: > > That's fine as long as they're giving you a resource that can potentially > > transfer the 20Mbps. > > > > That *is* a silly example. > > > > A more proper analogy would be that you buy 12 gallons of gas, but the > > station only deposits 11 gallons in your tank because the pumps are > > operated by gasoline engines and they feel it is fine to count the > > number of gallons pulled out of their tank instead of the amount given > > to the customer. > > > > > > Finding new ways to give the customer less while making it look like more > > has a long, proud history, yes. > > > > ... JG > > -- > Jeff Sorrels > Network Administrator > KanREN, Inc > jlsorrels at kanren.net > 785-856-9820, #2 > > > From zcfrederick at gmail.com Fri Oct 31 18:32:55 2014 From: zcfrederick at gmail.com (Zachary Frederick) Date: Fri, 31 Oct 2014 14:32:55 -0400 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom Message-ID: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> We have been having a problem receiving software releases from our developer. The releases are typically around 1G in size. The developer’s connection is a 100m metro fiber with TW Telecom, our connection is a 25m Comcast Enterprise Fiber. Our traffic graphs show very little utilization of our connection. Typically on average we are at about 7 meg utilization of our 25. Every other partner that shares in our software development that receives the software releases can receive the updates 3-4 times faster than we can. Typically we receive the releases at about 3mbps. I have tried contacting Comcast Enterprise Tech support, however I’ve been told that if I run a speed test from my connection and the test runs at the speed we are paying for, there is very little they are willing to look into. Can anyone check on the Comcast Routers on the Tracert below, or is there anything that can be throttling this connection between the two connections? Also, our firewall and connection is able to run at the full 25. We have no throttling or QOS set to prevent a good connection to our developer. For example, we can run a multi-threaded upload, in the middle of the night, to Amazon Glacier storage and completely saturate our connection when doing so. The firewall and connection is able to handle our full bandwidth capacity during that backup. If there is any other information I can provide to help track this problem down, please let me know. Thanks in advance, everyone! Trace Route below: 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms 10.485 ms 10.478 ms 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) 10.470 ms 10.465 ms 10.457 ms 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) 10.733 ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.33) 12.146 ms 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms 32.144 ms 32.127 ms 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net (162.151.21.82) 44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net (69.139.195.18) 38.266 ms 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms From mysidia at gmail.com Fri Oct 31 18:51:59 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 31 Oct 2014 13:51:59 -0500 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: <20141031173933.GA26681@puck.nether.net> References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch wrote: [snip] > People tend to treat things like IRR (eg: RADB, etc) as a > garbage pit you toss things into and never remove from. So who do we ask about making IRRs expire defunct objects and/or changing their system design to ensure that the legitimate resource holder can remove references to their prefix from ASes they no longer authorize to carry them, without requiring all sorts of assistance, cooperation, and willingness from the AS maintainer? :) >> Is this a non-issue that I shouldn't worry about? Doesn't the >> quality of this data effect Origin Validation efforts? > > Yes it does. This has a fairly severe impact for those that build > off the IRR data for filters. We have seen customers end up including > AS7018 in their AS-SET or as you noticed have other legacy routes appear. > -- -JH From pmsac.nanog at gmail.com Fri Oct 31 19:02:34 2014 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 31 Oct 2014 19:02:34 +0000 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom In-Reply-To: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> References: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> Message-ID: On 31 October 2014 18:32, Zachary Frederick wrote: > We have been having a problem receiving software releases from our > developer. The releases are typically around 1G in size. The developer’s > connection is a 100m metro fiber with TW Telecom, our connection is a 25m > Comcast Enterprise Fiber. > > Our traffic graphs show very little utilization of our connection. > Typically on average we are at about 7 meg utilization of our 25. > > Every other partner that shares in our software development that receives > the software releases can receive the updates 3-4 times faster than we can. > > Typically we receive the releases at about 3mbps. > Are you using an application that uses TCP transport for the transfer? https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64 3Mbps looks about right. Time for a tune up > I have tried contacting Comcast Enterprise Tech support, however I’ve been > told that if I run a speed test from my connection and the test runs at the > speed we are paying for, there is very little they are willing to look into. > > Can anyone check on the Comcast Routers on the Tracert below, or is there > anything that can be throttling this connection between the two connections? > > Also, our firewall and connection is able to run at the full 25. We have > no throttling or QOS set to prevent a good connection to our developer. For > example, we can run a multi-threaded upload, in the middle of the night, to > Amazon Glacier storage and completely saturate our connection when doing > so. The firewall and connection is able to handle our full bandwidth > capacity during that backup. > > If there is any other information I can provide to help track this problem > down, please let me know. > > Thanks in advance, everyone! > > > Trace Route below: > > > > > 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms > > > 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms > > > 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms > 10.485 ms 10.478 ms > > > 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) > 10.470 ms 10.465 ms 10.457 ms > > > 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) 10.733 > ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net > (68.86.86.33) 12.146 ms > > > 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms > 32.144 ms 32.127 ms > > > 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms > > > 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net > (162.151.21.82) 44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net > (69.139.195.18) 38.266 ms > > > 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms From frnkblk at iname.com Fri Oct 31 19:09:30 2014 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 31 Oct 2014 14:09:30 -0500 Subject: Industry standard bandwidth guarantee? In-Reply-To: <2B7669201D58CD4C8A2150DB12B129CF165714E6D3@FHDP1LUMXC7V43.us.one.verizon.com> References: <201410311102.s9VB2STR074846@aurora.sol.net> <78C35D6C1A82D243B830523B4193CF5F75CAC0683D@SBS1.blinker.local> <2B7669201D58CD4C8A2150DB12B129CF165714E6D3@FHDP1LUMXC7V43.us.one.verizon.com> Message-ID: <000e01cff53e$32ed6570$98c83050$@iname.com> We get this with wireless carriers -- they ask for quote for a 100 Mbps Ethernet circuit, and then tell us afterwards that it's 100 Mbps of goodput, so we have to size it to 125 Mbps to cover all their one MPLS and two 802.1Q tags and to past the RFC 2544 test at 64-byte frames. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bacon, Ricky (RJ) Sent: Friday, October 31, 2014 11:50 AM To: David Hofstee; nanog at nanog.org Subject: RE: Industry standard bandwidth guarantee? >That *is* a silly example. > >A more proper analogy would be that you buy 12 gallons of gas, but the >station only deposits 11 gallons in your tank because the pumps are operated by gasoline engines and they feel it is fine to count the number of gallons pulled out of their tank instead of the amount given to the customer. So if you tell a customer you are giving them 10 g of space for their email, you shouldn't charge them for the storage taken up by each individual email's headers. Is that how it works though? Not so much I think. As long as the pricing policy is consistent across the industry, and it is, then you are not being ripped off. Creating, implementing and maintaining a deep dive billing systems to figure out how much of your traffic is packet header and protocol and how much is your data would just add to operating expense which would eventually be passed on to the customer. If you want a pipe that will let you transmit 10G of raw data, I can have than implemented. Just tell me where to connect the two ends. If you want to connect one end to our router or switch, we'll do that too, but it won't get you much. If you want to participate on the internet with a 10Gig link, you are going to have to use protocols, and the data will have to be in layer 3 packets, and they can be any kind you choose. But you are originating the request packets and receiving the reply packets and those will include overhead. We just transport them to and from the internet. In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download limitation in bits per second. You will not exceed that unless you run multiple sessions, and even then it will always be less than link speed, which is your physical limit, how many bits you can receive in a second, protocol or otherwise. From carlos at race.com Fri Oct 31 19:25:01 2014 From: carlos at race.com (Carlos Alcantar) Date: Fri, 31 Oct 2014 19:25:01 +0000 Subject: Industry standard bandwidth guarantee? In-Reply-To: <00d801cff52b$a2c0d8e0$e8428aa0$@heliacal.net> References: <201410311102.s9VB2STR074846@aurora.sol.net> <5453B55A.2040505@kanren.net> <00d801cff52b$a2c0d8e0$e8428aa0$@heliacal.net> Message-ID: +1 on this exactly what we do, keeps the calls down. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 10/31/14, 9:56 AM, "Laszlo Hanyecz" wrote: >If you're selling to end users, under promise and over deliver. Tell them >20Mbit but provision for 25. That way when they run their speedtest, >they're delighted that they're getting more, instead of being disappointed >and feeling screwed. In practice they will leave it idle most of the time >anyway. >This isn't a technical problem, it's just a matter of setting expectations >and satisfying them. Some of the customers might be completely clueless, >but if your goal is to make them happy, then explaining protocol overhead >is >probably not the right way. > >-Laszlo > > > > > From jneiberger at gmail.com Fri Oct 31 19:27:28 2014 From: jneiberger at gmail.com (John Neiberger) Date: Fri, 31 Oct 2014 13:27:28 -0600 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom In-Reply-To: References: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> Message-ID: With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s or 1.75 Mbps. https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate But that's only if either endpoint is stuck at a 64 KB receive window. A quick packet capture would be able to see what was happening. Check the TCP setup and make sure that both ends are doing TCP window scaling properly. John On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca wrote: > On 31 October 2014 18:32, Zachary Frederick wrote: > > > We have been having a problem receiving software releases from our > > developer. The releases are typically around 1G in size. The developer’s > > connection is a 100m metro fiber with TW Telecom, our connection is a > 25m > > Comcast Enterprise Fiber. > > > > Our traffic graphs show very little utilization of our connection. > > Typically on average we are at about 7 meg utilization of our 25. > > > > Every other partner that shares in our software development that receives > > the software releases can receive the updates 3-4 times faster than we > can. > > > > Typically we receive the releases at about 3mbps. > > > > Are you using an application that uses TCP transport for the transfer? > > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64 > > 3Mbps looks about right. Time for a tune up > > > > I have tried contacting Comcast Enterprise Tech support, however I’ve > been > > told that if I run a speed test from my connection and the test runs at > the > > speed we are paying for, there is very little they are willing to look > into. > > > > Can anyone check on the Comcast Routers on the Tracert below, or is there > > anything that can be throttling this connection between the two > connections? > > > > Also, our firewall and connection is able to run at the full 25. We have > > no throttling or QOS set to prevent a good connection to our developer. > For > > example, we can run a multi-threaded upload, in the middle of the night, > to > > Amazon Glacier storage and completely saturate our connection when doing > > so. The firewall and connection is able to handle our full bandwidth > > capacity during that backup. > > > > If there is any other information I can provide to help track this > problem > > down, please let me know. > > > > Thanks in advance, everyone! > > > > > > Trace Route below: > > > > > > > > > > 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms > > > > > > 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms > > > > > > 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms > > 10.485 ms 10.478 ms > > > > > > 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) > > 10.470 ms 10.465 ms 10.457 ms > > > > > > 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) 10.733 > > ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net > > (68.86.86.33) 12.146 ms > > > > > > 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms > > 32.144 ms 32.127 ms > > > > > > 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms > > > > > > 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) > > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net > > (162.151.21.82) 44.644 ms > te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net > > (69.139.195.18) 38.266 ms > > > > > > 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms > From zcfrederick at gmail.com Fri Oct 31 19:29:56 2014 From: zcfrederick at gmail.com (Zachary Frederick) Date: Fri, 31 Oct 2014 15:29:56 -0400 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom In-Reply-To: References: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> Message-ID: <22F2BA81-CB37-4805-9659-139970B12303@gmail.com> I apologize I should have said it starts out about 3 meg max and slows to about 400kpbs for most of the transfer. > On Oct 31, 2014, at 3:27 PM, John Neiberger wrote: > > With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s or 1.75 Mbps. > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate > > But that's only if either endpoint is stuck at a 64 KB receive window. A quick packet capture would be able to see what was happening. Check the TCP setup and make sure that both ends are doing TCP window scaling properly. > > John > > On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca > wrote: > On 31 October 2014 18:32, Zachary Frederick > wrote: > > > We have been having a problem receiving software releases from our > > developer. The releases are typically around 1G in size. The developer’s > > connection is a 100m metro fiber with TW Telecom, our connection is a 25m > > Comcast Enterprise Fiber. > > > > Our traffic graphs show very little utilization of our connection. > > Typically on average we are at about 7 meg utilization of our 25. > > > > Every other partner that shares in our software development that receives > > the software releases can receive the updates 3-4 times faster than we can. > > > > Typically we receive the releases at about 3mbps. > > > > Are you using an application that uses TCP transport for the transfer? > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64 > > 3Mbps looks about right. Time for a tune up > > > > I have tried contacting Comcast Enterprise Tech support, however I’ve been > > told that if I run a speed test from my connection and the test runs at the > > speed we are paying for, there is very little they are willing to look into. > > > > Can anyone check on the Comcast Routers on the Tracert below, or is there > > anything that can be throttling this connection between the two connections? > > > > Also, our firewall and connection is able to run at the full 25. We have > > no throttling or QOS set to prevent a good connection to our developer. For > > example, we can run a multi-threaded upload, in the middle of the night, to > > Amazon Glacier storage and completely saturate our connection when doing > > so. The firewall and connection is able to handle our full bandwidth > > capacity during that backup. > > > > If there is any other information I can provide to help track this problem > > down, please let me know. > > > > Thanks in advance, everyone! > > > > > > Trace Route below: > > > > > > > > > > 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms > > > > > > 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms > > > > > > 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms > > 10.485 ms 10.478 ms > > > > > > 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) > > 10.470 ms 10.465 ms 10.457 ms > > > > > > 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) 10.733 > > ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net > > (68.86.86.33) 12.146 ms > > > > > > 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms > > 32.144 ms 32.127 ms > > > > > > 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms > > > > > > 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) > > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net > > (162.151.21.82) 44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net > > (69.139.195.18) 38.266 ms > > > > > > 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms > From jneiberger at gmail.com Fri Oct 31 19:37:24 2014 From: jneiberger at gmail.com (John Neiberger) Date: Fri, 31 Oct 2014 13:37:24 -0600 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom In-Reply-To: <22F2BA81-CB37-4805-9659-139970B12303@gmail.com> References: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> <22F2BA81-CB37-4805-9659-139970B12303@gmail.com> Message-ID: Sounds like a combination of packet loss and small TCP receive windows. If you can, grab a packet capture and make sure to get the TCP setup. That should show you what's happening under the hood. Also, I should mention that I totally hosed the units in my first reply. :) That's what I get for hurrying. John On Fri, Oct 31, 2014 at 1:29 PM, Zachary Frederick wrote: > I apologize I should have said it starts out about 3 meg max and slows to > about 400kpbs for most of the transfer. > > > > On Oct 31, 2014, at 3:27 PM, John Neiberger wrote: > > With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like > 14MB/s or 1.75 Mbps. > > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate > > But that's only if either endpoint is stuck at a 64 KB receive window. A > quick packet capture would be able to see what was happening. Check the > TCP setup and make sure that both ends are doing TCP window scaling > properly. > > John > > On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca > wrote: > >> On 31 October 2014 18:32, Zachary Frederick >> wrote: >> >> > We have been having a problem receiving software releases from our >> > developer. The releases are typically around 1G in size. The developer’s >> > connection is a 100m metro fiber with TW Telecom, our connection is a >> 25m >> > Comcast Enterprise Fiber. >> > >> > Our traffic graphs show very little utilization of our connection. >> > Typically on average we are at about 7 meg utilization of our 25. >> > >> > Every other partner that shares in our software development that >> receives >> > the software releases can receive the updates 3-4 times faster than we >> can. >> > >> > Typically we receive the releases at about 3mbps. >> > >> >> Are you using an application that uses TCP transport for the transfer? >> >> >> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64 >> >> 3Mbps looks about right. Time for a tune up >> >> >> > I have tried contacting Comcast Enterprise Tech support, however I’ve >> been >> > told that if I run a speed test from my connection and the test runs at >> the >> > speed we are paying for, there is very little they are willing to look >> into. >> > >> > Can anyone check on the Comcast Routers on the Tracert below, or is >> there >> > anything that can be throttling this connection between the two >> connections? >> > >> > Also, our firewall and connection is able to run at the full 25. We have >> > no throttling or QOS set to prevent a good connection to our developer. >> For >> > example, we can run a multi-threaded upload, in the middle of the >> night, to >> > Amazon Glacier storage and completely saturate our connection when doing >> > so. The firewall and connection is able to handle our full bandwidth >> > capacity during that backup. >> > >> > If there is any other information I can provide to help track this >> problem >> > down, please let me know. >> > >> > Thanks in advance, everyone! >> > >> > >> > Trace Route below: >> > >> > >> > >> > >> > 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms >> > >> > >> > 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms >> > >> > >> > 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms >> > 10.485 ms 10.478 ms >> > >> > >> > 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) >> > 10.470 ms 10.465 ms 10.457 ms >> > >> > >> > 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) >> 10.733 >> > ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net >> > (68.86.86.33) 12.146 ms >> > >> > >> > 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms >> > 32.144 ms 32.127 ms >> > >> > >> > 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms >> > >> > >> > 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) >> > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net >> > (162.151.21.82) 44.644 ms >> te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net >> > (69.139.195.18) 38.266 ms >> > >> > >> > 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms >> > > > From mprice at tqhosting.com Fri Oct 31 19:41:43 2014 From: mprice at tqhosting.com (Mark Price) Date: Fri, 31 Oct 2014 15:41:43 -0400 Subject: Comcast throttling? Message-ID: Similar to another thread on the list today, I'm troubleshooting a problem for a customer on Comcast business fiber. Downloading a file from one of our web servers is very slow (~15KByte/sec). mtr looks clean in both directions. I added an IP address on the same server from a different class C on our network, and downloads form this new IP are fast (2MByte/sec). Tracerouting from server to client is the same using both source IPs. But, one IP consistently has the very slow speeds that the other does not. Changing our outbound path between different upstreams does not make a difference. It certainly feels like Comcast is throttling one of our IP ranges. Could someone at Comcast please contact me off-list for details? Thanks, Mark From jared at puck.Nether.net Fri Oct 31 19:41:56 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 31 Oct 2014 15:41:56 -0400 Subject: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom In-Reply-To: <22F2BA81-CB37-4805-9659-139970B12303@gmail.com> References: <982B57DE-C923-464A-BEDF-667F2D0818E3@gmail.com> <22F2BA81-CB37-4805-9659-139970B12303@gmail.com> Message-ID: <20141031194156.GB26681@puck.nether.net> Recommendations: 1) Use iperf in TCP mode to test the performance 2) use iperf in UDP mode to test the performance This is the best way to quickly triage the issue and determine if it's actual bandwidth issue or something else. It's quite common for various NAT/VPN devices to eat or meddle with packets such that performance is limited, sometimes severely. You need to check the CPU/performance of these devices. Do you have graphs showing the links as idle for each end while doing the test? Many people don't have this data or tools. Consider setting up a tool like observium to monitor the health and performance of the devices. Check other devices, such as switches, duplex settings, etc. If the device is 'unmanaged' and you can't tell if it negotiated 100-full or 100-half, consider it may have done half-duplex. I recall one customer case where after much troubleshooting for performance they had a duplex issue causing trouble. Hope this helps, - Jared On Fri, Oct 31, 2014 at 03:29:56PM -0400, Zachary Frederick wrote: > I apologize I should have said it starts out about 3 meg max and slows to about 400kpbs for most of the transfer. > > > > > On Oct 31, 2014, at 3:27 PM, John Neiberger wrote: > > > > With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s or 1.75 Mbps. > > > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate > > > > But that's only if either endpoint is stuck at a 64 KB receive window. A quick packet capture would be able to see what was happening. Check the TCP setup and make sure that both ends are doing TCP window scaling properly. > > > > John > > > > On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca > wrote: > > On 31 October 2014 18:32, Zachary Frederick > wrote: > > > > > We have been having a problem receiving software releases from our > > > developer. The releases are typically around 1G in size. The developer’s > > > connection is a 100m metro fiber with TW Telecom, our connection is a 25m > > > Comcast Enterprise Fiber. > > > > > > Our traffic graphs show very little utilization of our connection. > > > Typically on average we are at about 7 meg utilization of our 25. > > > > > > Every other partner that shares in our software development that receives > > > the software releases can receive the updates 3-4 times faster than we can. > > > > > > Typically we receive the releases at about 3mbps. > > > > > > > Are you using an application that uses TCP transport for the transfer? > > > > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64 > > > > 3Mbps looks about right. Time for a tune up > > > > > > > I have tried contacting Comcast Enterprise Tech support, however I’ve been > > > told that if I run a speed test from my connection and the test runs at the > > > speed we are paying for, there is very little they are willing to look into. > > > > > > Can anyone check on the Comcast Routers on the Tracert below, or is there > > > anything that can be throttling this connection between the two connections? > > > > > > Also, our firewall and connection is able to run at the full 25. We have > > > no throttling or QOS set to prevent a good connection to our developer. For > > > example, we can run a multi-threaded upload, in the middle of the night, to > > > Amazon Glacier storage and completely saturate our connection when doing > > > so. The firewall and connection is able to handle our full bandwidth > > > capacity during that backup. > > > > > > If there is any other information I can provide to help track this problem > > > down, please let me know. > > > > > > Thanks in advance, everyone! > > > > > > > > > Trace Route below: > > > > > > > > > > > > > > > 1 (172.16.150.1) 1.143 ms 1.132 ms 1.122 ms > > > > > > > > > 2 (173.227.204.1) 1.585 ms 1.583 ms 1.574 ms > > > > > > > > > 3 chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166) 10.477 ms > > > 10.485 ms 10.478 ms > > > > > > > > > 4 x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141) > > > 10.470 ms 10.465 ms 10.457 ms > > > > > > > > > 5 he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37) 10.733 > > > ms 10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net > > > (68.86.86.33) 12.146 ms > > > > > > > > > 6 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 33.202 ms > > > 32.144 ms 32.127 ms > > > > > > > > > 7 68.86.91.30 (68.86.91.30) 41.508 ms 41.322 ms 41.599 ms > > > > > > > > > 8 te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26) > > > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net > > > (162.151.21.82) 44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net > > > (69.139.195.18) 38.266 ms > > > > > > > > > 9 (107.1.72.98) 39.781 ms 39.785 ms 39.912 ms > > > -- 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 jneiberger at gmail.com Fri Oct 31 19:55:13 2014 From: jneiberger at gmail.com (John Neiberger) Date: Fri, 31 Oct 2014 13:55:13 -0600 Subject: Comcast throttling? In-Reply-To: References: Message-ID: Replying off-list as requested. John On Fri, Oct 31, 2014 at 1:41 PM, Mark Price wrote: > Similar to another thread on the list today, I'm troubleshooting a problem > for a customer on Comcast business fiber. > > Downloading a file from one of our web servers is very slow (~15KByte/sec). > mtr looks clean in both directions. I added an IP address on the same > server from a different class C on our network, and downloads form this new > IP are fast (2MByte/sec). > > Tracerouting from server to client is the same using both source IPs. But, > one IP consistently has the very slow speeds that the other does not. > Changing our outbound path between different upstreams does not make a > difference. > > It certainly feels like Comcast is throttling one of our IP ranges. Could > someone at Comcast please contact me off-list for details? > > > Thanks, > > Mark > From streiner at cluebyfour.org Fri Oct 31 20:00:01 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 31 Oct 2014 16:00:01 -0400 (EDT) Subject: Comcast throttling? In-Reply-To: References: Message-ID: On Fri, 31 Oct 2014, Mark Price wrote: > Similar to another thread on the list today, I'm troubleshooting a problem > for a customer on Comcast business fiber. > > Downloading a file from one of our web servers is very slow (~15KByte/sec). > mtr looks clean in both directions. I added an IP address on the same > server from a different class C on our network, and downloads form this new > IP are fast (2MByte/sec). > > Tracerouting from server to client is the same using both source IPs. But, > one IP consistently has the very slow speeds that the other does not. > Changing our outbound path between different upstreams does not make a > difference. > > It certainly feels like Comcast is throttling one of our IP ranges. Could > someone at Comcast please contact me off-list for details? That's possible, but while a traceroute can help shed some light on certain performance problems, this doesn't seem like one where a traceroute will help very much. The slow traceroute hops are more likely due to other factors (ICMP rate limiting / control plane policing / etc), rather than a direct indicator of Comcast shaping / throttling your traffic. As others have indicated, doing a packet capture of a transfer session that shows the behavior you noted is likely to be a lot more telling than a traceroute. jms From Valdis.Kletnieks at vt.edu Fri Oct 31 20:45:27 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 31 Oct 2014 16:45:27 -0400 Subject: Comcast throttling? In-Reply-To: Your message of "Fri, 31 Oct 2014 15:41:43 -0400." References: Message-ID: <33034.1414788327@turing-police.cc.vt.edu> On Fri, 31 Oct 2014 15:41:43 -0400, Mark Price said: > Similar to another thread on the list today, I'm troubleshooting a problem > for a customer on Comcast business fiber. > > Downloading a file from one of our web servers is very slow (~15KByte/sec). I recently hit a similar problem, tracked it down to a brain-dead firewall owner that had configured the gear to change the TCP WSCALE header option to NOPs. Hilarity ensues when the sender thinks the window is 389 bytes rather than 389<<10 bytes. Yes, you *would* think that sort of tomfoolery went out with the last century, but it's amazing how long people will re-invent bad ideas.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Oct 31 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Oct 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201410312200.s9VM00rC002017@wattle.apnic.net> This report has been generated at Fri Oct 31 21:14:13 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-10-14 521614 289252 25-10-14 522066 289302 26-10-14 522320 289236 27-10-14 521998 289212 28-10-14 522002 289264 29-10-14 522115 289231 30-10-14 525540 288920 31-10-14 525536 289245 AS Summary 48695 Number of ASes in routing system 19584 Number of ASes announcing only one prefix 3035 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120193024 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 31Oct14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 527072 289246 237826 45.1% All ASes AS13184 2928 21 2907 99.3% HANSENET Telefonica Germany GmbH & Co.OHG,DE AS6389 2894 108 2786 96.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2824 83 2741 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2847 163 2684 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2572 115 2457 95.5% NET Servi�os de Comunica��o S.A.,BR AS4766 2951 1334 1617 54.8% KIXS-AS-KR Korea Telecom,KR AS6147 1780 166 1614 90.7% Telefonica del Peru S.A.A.,PE AS7303 1769 290 1479 83.6% Telecom Argentina S.A.,AR AS9808 1475 53 1422 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1371 25 1346 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1920 632 1288 67.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2444 1157 1287 52.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1816 557 1259 69.3% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1643 410 1233 75.0% TWTC - tw telecom holdings, inc.,US AS10620 3035 1813 1222 40.3% Telmex Colombia S.A.,CO AS9498 1314 111 1203 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2044 869 1175 57.5% MEGAPATH5-US - MegaPath Corporation,US AS7552 1210 51 1159 95.8% VIETEL-AS-AP Viettel Corporation,VN AS6983 1542 400 1142 74.1% ITCDELTA - Earthlink, Inc.,US AS7029 2137 1112 1025 48.0% WINDSTREAM - Windstream Communications Inc,US AS22561 1321 298 1023 77.4% AS22561 - CenturyTel Internet Holdings, Inc.,US AS4812 1523 507 1016 66.7% CHINANET-SH-AP China Telecom (Group),CN AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS34984 1840 927 913 49.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS56040 892 30 862 96.6% CMNET-GUANGDONG-AP China Mobile communications corporation,CN AS38285 978 131 847 86.6% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4788 1086 247 839 77.3% TMNET-AS-AP TM Net, Internet Service Provider,MY AS24560 1179 349 830 70.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18881 860 56 804 93.5% Global Village Telecom,BR AS31148 1045 258 787 75.3% FREENET-AS Freenet Ltd.,UA Total 54239 12356 41883 77.2% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.160.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.164.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.168.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.172.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.176.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.180.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.184.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.188.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.220.173.0/24 AS30058 FDCSERVERS - FDCservers.net,US 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.44.225.0/24 AS13374 HYTL-AS-AP HONGKONG YABOIDC TECHNOLOGY LIMITED,HK 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 177.221.176.0/24 AS52673 , 177.221.177.0/24 AS52673 , 177.221.178.0/24 AS52673 , 177.221.179.0/24 AS52673 , 177.221.180.0/24 AS52673 , 177.221.181.0/24 AS52673 , 177.221.182.0/24 AS52673 , 177.221.183.0/24 AS52673 , 177.221.184.0/24 AS52673 , 177.221.185.0/24 AS52673 , 177.221.186.0/24 AS52673 , 177.221.187.0/24 AS52673 , 177.221.188.0/24 AS52673 , 177.221.189.0/24 AS52673 , 177.221.190.0/24 AS52673 , 177.221.191.0/24 AS52673 , 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.75.120.0/22 AS19872 TXRX-AS TXRX Communications Ltd,GB 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.7.160.0/21 AS13703 BROADRIVER-13703 - BroadRiver Communication Corp.,US 199.7.162.0/24 AS22626 -Reserved AS-,ZZ 199.7.167.0/24 AS22626 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.116.212.0/22 AS53704 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 cidr-report at potaroo.net Fri Oct 31 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Oct 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201410312200.s9VM02Ma002036@wattle.apnic.net> BGP Update Report Interval: 23-Oct-14 -to- 30-Oct-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 201970 4.6% 1655.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS14287 177579 4.1% 25368.4 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 3 - AS9829 112487 2.6% 67.6 -- BSNL-NIB National Internet Backbone,IN 4 - AS56116 109395 2.5% 935.0 -- HWXD Beijing Hongweixinda Sci-Tech Development Co. Ltd.,CN 5 - AS12696 79634 1.8% 6125.7 -- AXA-TECH GIE AXA Technology Services France,FR 6 - AS45786 77866 1.8% 1112.4 -- HTSNET-AS-ID HTSNET - ISP,ID 7 - AS45899 68836 1.6% 110.8 -- VNPT-AS-VN VNPT Corp,VN 8 - AS5384 60794 1.4% 364.0 -- EMIRATES-INTERNET Emirates Telecommunications Corporation,AE 9 - AS13682 45436 1.0% 7572.7 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 10 - AS51964 34162 0.8% 146.0 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 11 - AS28573 28709 0.7% 18.2 -- NET Servi�os de Comunica��o S.A.,BR 12 - AS7643 28624 0.7% 83.0 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT),VN 13 - AS3313 27721 0.6% 13860.5 -- INET-AS BT Italia S.p.A.,IT 14 - AS48159 24149 0.6% 88.5 -- TIC-AS Telecommunication Infrastructure Company,IR 15 - AS4787 23487 0.5% 81.6 -- ASN-CBN Internet Service Provider,ID 16 - AS8402 23066 0.5% 75.9 -- CORBINA-AS OJSC "Vimpelcom",RU 17 - AS23342 22188 0.5% 568.9 -- UNITEDLAYER - Unitedlayer, Inc.,US 18 - AS60725 20431 0.5% 5107.8 -- O3B-AS O3b Limited,JE 19 - AS25003 19969 0.5% 587.3 -- INTERNET_BINAT Internet Binat Ltd,IL 20 - AS9583 18692 0.4% 16.3 -- SIFY-AS-IN Sify Limited,IN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14287 177579 4.1% 25368.4 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 2 - AS61039 16125 0.4% 16125.0 -- ZMZ OAO ZMZ,RU 3 - AS3313 27721 0.6% 13860.5 -- INET-AS BT Italia S.p.A.,IT 4 - AS18135 10293 0.2% 10293.0 -- BTV BTV Cable television,JP 5 - AS13682 45436 1.0% 7572.7 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 6 - AS12696 79634 1.8% 6125.7 -- AXA-TECH GIE AXA Technology Services France,FR 7 - AS6629 10751 0.2% 5375.5 -- NOAA-AS - NOAA,US 8 - AS25983 15641 0.4% 5213.7 -- SHAW-ENVISION - Enmax Envision Inc.,CA 9 - AS60725 20431 0.5% 5107.8 -- O3B-AS O3b Limited,JE 10 - AS62174 4929 0.1% 4929.0 -- INTERPAN-AS INTERPAN LTD.,BG 11 - AS56636 2878 0.1% 2878.0 -- ASVEDARU VEDA Ltd.,RU 12 - AS57734 2271 0.1% 2271.0 -- FRANCEIX France IX Services SASU,FR 13 - AS35093 4371 0.1% 2185.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 14 - AS52729 3685 0.1% 1842.5 -- BrNet Informatica,BR 15 - AS57201 1833 0.0% 1833.0 -- EDF-AS Estonian Defence Forces,EE 16 - AS30944 1716 0.0% 1716.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 17 - AS34023 1659 0.0% 1659.0 -- CITYLINE-AS PE Shattah Zia G.Naman,UA 18 - AS3 1659 0.0% 2975.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 19 - AS23752 201970 4.6% 1655.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 20 - AS3 1647 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 101161 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 98790 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.61.101.0/24 77294 1.7% AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID AS65001 -- -Private Use AS-,ZZ 4 - 208.78.116.0/22 35518 0.8% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 5 - 208.88.232.0/22 35514 0.8% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 6 - 208.73.244.0/22 35514 0.8% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 7 - 216.162.0.0/20 35514 0.8% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - 208.70.20.0/22 35508 0.8% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - 64.29.130.0/24 22002 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 10 - 192.115.44.0/22 19905 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 11 - 91.235.169.0/24 16125 0.3% AS61039 -- ZMZ OAO ZMZ,RU 12 - 71.19.134.0/23 14315 0.3% AS3313 -- INET-AS BT Italia S.p.A.,IT 13 - 194.153.99.0/24 13406 0.3% AS3313 -- INET-AS BT Italia S.p.A.,IT 14 - 202.123.86.0/24 12021 0.3% AS10098 -- HENDERSON-HK Henderson Data Centre Limited,HK 15 - 200.119.160.0/19 11177 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 16 - 190.143.240.0/20 11120 0.2% AS13682 -- TELEFONICA MOVILES GUATEMALA S.A.,GT 17 - 162.249.183.0/24 10978 0.2% AS60725 -- O3B-AS O3b Limited,JE 18 - 192.58.232.0/24 10750 0.2% AS6629 -- NOAA-AS - NOAA,US 19 - 42.83.48.0/20 10293 0.2% AS18135 -- BTV BTV Cable television,JP 20 - 185.26.155.0/24 9438 0.2% AS60725 -- O3B-AS O3b Limited,JE 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 rfg at tristatelogic.com Fri Oct 31 23:20:02 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 31 Oct 2014 16:20:02 -0700 Subject: Hijacking machine: ASAS201640 / AS200002 Message-ID: <22155.1414797602@server1.tristatelogic.com> I don't routinely follow this list, so I'm not sure how much of this is common knowledge already, but... http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/ Current route announcements for AS201640: 36.0.56.0/21 probable hijack - China 41.92.206.0/23 probable hijack - Cameroon 41.198.80.0/20 probable hijack - South Africa 41.198.224.0/20 probable hijack - South Africa 61.242.128.0/19 probable hijack - China 119.227.224.0/19 probable hijack - India 123.29.96.0/19 probable hijack - Vietnam 177.22.117.0/24 probable hijack - Brazil 187.189.158.0/23 probable hijack - Mexico 202.39.112.0/20 probable hijack - Taiwan Network Information Center 210.57.0.0/19 probable hijack - Telstra/Japan It would appear that AS201640 may possibly exist at the present time only for the purpose of providing illicitly obtained IP space for spammers, including but not limited to the ""Mike Prescott" mentioned in the Cisco blog entry cited above. The spammer, "Mike Prescott"... not his real last name... has also been spotted spewing from IP space routed by AS200002, which is AS201640's only connection to the rest of the world. Coincidence? You be the judge. Regards, rfg P.S. If anybody is able to look up _all_ of the route announcements that have been made by AS201640 over the past few months, I for one would definitely like to see those. Please e-mail them to me off list. I already know that "Mike Prescott" has been spewing from at least one of the above current announcements (202.39.112.0/20) and probably all of the others too. But there are additional route announcements that have already been withdrawn, and I'd like to check those for "Mike Prescott" footprints also. P.P.S. To the real "Mike P."... on the off chance that he might see this... You can run, but you don't hide very well. You should have gotten out of the game in 1998 when you had the chance. Maybe the Powers That Be will lock you up this time. From ak at ghostnet.de Fri Oct 31 23:55:32 2014 From: ak at ghostnet.de (Armin Kneip) Date: Sat, 01 Nov 2014 00:55:32 +0100 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <22155.1414797602@server1.tristatelogic.com> References: <22155.1414797602@server1.tristatelogic.com> Message-ID: <54542174.30809@ghostnet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ronald, > P.S. If anybody is able to look up _all_ of the route announcements that > have been made by AS201640 over the past few months, I for one would > definitely like to see those. Please e-mail them to me off list. I > already know that "Mike Prescott" has been spewing from at least one of the > above current announcements (202.39.112.0/20) and probably all of the > others too. But there are additional route announcements that have already > been withdrawn, and I'd like to check those for "Mike Prescott" footprints > also. > http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640 http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=200002 or http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0 http://www.cidr-report.org/cgi-bin/as-report?as=AS200002&view=2.0 - -- Mit freundlichen Grüßen // Kind regards Armin Kneip Network & System Operator ASN: 12586, 31025 Mail: ak at ghostnet.de PGP ID: 0x563C099C Fingerprint: CE89 0605 5E21 5611 E526 72DD 759F 4DAA 563C 099C GHOSTnet GmbH Kaiser-Friedrich-Promenade 65 D-61348 Bad Homburg v.d.H (Germany) Office +49 (0) 6172 185025 Fax +49 (0) 6172 185029 Internet: www.ghostnet.de Mail: noc at ghostnet.de Sitz: Kaiser-Friedrich-Promenade 65, D-61348 Bad Homburg v.d.H. Amtsgericht Bad Homburg v.d.H. HRB 8637, UST-ID-Nr. DE206435465 Geschäftsführer: Sebastian Grafmüller -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJUVCFzAAoJEHWfTapWPAmcfAcP/3Xw+GDthe/WNFCWlbBAS0/k zBM9aTlUzrhDVxCz73GBLxQQdsEAdff4E2vBfFXJDcXC7zVbmom2HSXj9IaolL2W dTW9N6zAkhMpKObCMhBZtSuQwYxz7rgNZVJlBVnzu6wOiNTc0lbrxeZ61hKYPAhe Sjk+Tqs/upkLehR7A37J1KW0rc8nSQ5yEXQl0Qi59CaDc89/ACfeSWk60ugQJ6DC rtat/HnDQEwdBWbbvBHlBAhqD7ILgdVa/72JsaXjpV4g2w7WwJFIYmOL+DqgnPyO jpWNzfo3rV/Kpbx4T0Cn5wsjWHzwzv3MjHB2R4sVbN92P3TAXonjBxT8T+3t+9ab fcSBTpiNAuS6iJg93e52FnMmlb3c/8ZwIutB3mjC8Ktlq6eBK9bufprF5pInc7Ge sEZxv25ZPdh0xb0NAkfXBB8Jf1gVFLchQWk8L7Zfzb4UdsLPNx4w9/rkP7vasMaW gvWswMBECtCJ9L7vi0z6x4aer17BcdRrlRqWt1VJQDPUBC8sucilrF94Ov1TqiTL gusM6URVEQ9Rz9L6Lz7RuSVhv4fO4ROtb++5H6xdxwCklln+AiZsoCFgkwtOaWuV 97+MgWhtINKFu+XLfS5/uSZVAgj8IpqHRt0zXMRHtOzGICk0ZpTOb+1VjMkpYM7b 0YmXzW8KLdv024vpmQXZ =8Ta5 -----END PGP SIGNATURE-----