From daniel at fx.net.nz Mon Oct 1 01:39:08 2012 From: daniel at fx.net.nz (Daniel Griggs) Date: Mon, 1 Oct 2012 14:39:08 +1300 Subject: Angled Polish Connectors and DWDM In-Reply-To: <50687E40.4070604@kenweb.org> References: <5068608A.70606@kenweb.org> <50687E40.4070604@kenweb.org> Message-ID: We have been using APC connectors on our DWDM deployments now for about 5 years and have had no issues with it at all. Additionally, last year we engaged several DWDM system providers and one of the questions we asked them was, did they know of any issues with APC connectors especially with regard to dual polarization systems. All vendors came back with having no issues with APC connectors. On 1 October 2012 06:15, ML wrote: > On 9/30/2012 12:46 PM, Mikael Abrahamsson wrote: > >> On Sun, 30 Sep 2012, ML wrote: >> >> So far our PMD testing has come back clear. >>> >> >> How have you done the PMD testing? >> >> For verifying PMD and CD through an actual wavelength (not per-fiber, but >> through all the ADMs etc), I haven't really been able to find a good >> solution. Suggestions welcome. >> >> > All tests done per span on dark fiber. > > CDs via a Nettest FD440: 1520nm to 1640nm > PMD via a PerkinElmer* device: Just at 1550nm. > > -ML > > > Couldn't find a model number in the test results. Just a reference to > PerkinElmer. > > -- Daniel Griggs Network Operations e: daniel at fx.net.nz d: +64 4 4989567 From mohta at necom830.hpcl.titech.ac.jp Mon Oct 1 07:57:19 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 01 Oct 2012 16:57:19 +0900 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <5068CC6C.50001@ninjabadger.net> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068CC6C.50001@ninjabadger.net> Message-ID: <50694CDF.8000606@necom830.hpcl.titech.ac.jp> Tom Hill wrote: > Once you get your head (and wallet) around that, there becomes a case > for running each of your waves at 2.5x the rate they're employed at now. > The remaining question is then to decide if that's cheaper than running > more fibre. It depends on distance between senders and receivers. However, at certain distance it becomes impossible to use efficient (w.r.t. bits per symbol) encoding, because of noise of repeated EDFA amplification. > Still a hard one to justify though, I agree. For 50Gbps lane, it becomes even harder and, for 100Gbps lane, it will likely to be impossible. > I've recently seen a presentation from EPF** (by Juniper) that was > *very* interesting in the >100G race, from a technical perspective. Well > worth hunting that one down if you can, as it details a lot about optic > composition in future standards, optic densities/backplanes, etc. This one? http://www.peering-forum.eu/assets/presentations2012/JunpierEPF7.pdf But, it does not say much about >100G. Masataka Ohta From tom at ninjabadger.net Mon Oct 1 09:58:36 2012 From: tom at ninjabadger.net (tom at ninjabadger.net) Date: Mon, 01 Oct 2012 10:58:36 +0100 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <50694CDF.8000606@necom830.hpcl.titech.ac.jp> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068CC6C.50001@ninjabadger.net> <50694CDF.8000606@necom830.hpcl.titech.ac.jp> Message-ID: <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> On 2012-10-01 08:57, Masataka Ohta wrote: > Tom Hill wrote: > >> Once you get your head (and wallet) around that, there becomes a >> case >> for running each of your waves at 2.5x the rate they're employed at >> now. >> The remaining question is then to decide if that's cheaper than >> running >> more fibre. > > It depends on distance between senders and receivers. > > However, at certain distance it becomes impossible to use > efficient (w.r.t. bits per symbol) encoding, because of > noise of repeated EDFA amplification. <500km not enough? https://www.de-cix.net/news-events/latest-news/news/article/de-cix-chooses-adva-optical-networkings-100g-metro-solution/ >> Still a hard one to justify though, I agree. > > For 50Gbps lane, it becomes even harder and, for 100Gbps lane, > it will likely to be impossible. Tell this to Ciena... ;) If you can afford Wave Logic 3 interfaces for your Nortel^WCiena 6500's, you'll find some pretty impressive things are actually possible, including 100G per 100GHz guide over very large distances (think Atlantic-large). Coherence appears to be the secret sauce in pushing the SnR boundaries, albeit I'm not going to pretend to even understand the physics involved, I was just lucky enough to speak to some people that do. :) >> I've recently seen a presentation from EPF** (by Juniper) that was >> *very* interesting in the >100G race, from a technical perspective. >> Well >> worth hunting that one down if you can, as it details a lot about >> optic >> composition in future standards, optic densities/backplanes, etc. > > This one? > > http://www.peering-forum.eu/assets/presentations2012/JunpierEPF7.pdf > > But, it does not say much about >100G. Yes, that is the one. Slide #11 is the one I'm referring to, 'Projection of Form Factor Evolution to 400G', which is relevant to the discussion on optic densities and the push above 100G. Tom From swmike at swm.pp.se Mon Oct 1 10:18:32 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 1 Oct 2012 12:18:32 +0200 (CEST) Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068CC6C.50001@ninjabadger.net> <50694CDF.8000606@necom830.hpcl.titech.ac.jp> <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> Message-ID: On Mon, 1 Oct 2012, tom at ninjabadger.net wrote: > If you can afford Wave Logic 3 interfaces for your Nortel^WCiena 6500's, > you'll find some pretty impressive things are actually possible, > including 100G per 100GHz guide over very large distances (think > Atlantic-large). The amount of processing power and equipment in the transponder to achieve this is most likely out of scope for short term practical 400GE/1TBE that IEEE will put into standard. So serial lights on/off much faster than 25 Gbaud runs into serious physical limitations, as some physical effects increase 4-fold when you on/off blink 2 times as fast. That's why we do not have 100Gbaud 100GE, but instead 4x25Gbaud. > Coherence appears to be the secret sauce in pushing the SnR boundaries, > albeit I'm not going to pretend to even understand the physics involved, I > was just lucky enough to speak to some people that do. :) Yes, for long-haul DWDM systems coherent detection is absolutely the way to go. For short and metro reach at low cost, that is probably going to be a bit further into the future. -- Mikael Abrahamsson email: swmike at swm.pp.se From mohta at necom830.hpcl.titech.ac.jp Mon Oct 1 12:01:30 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 01 Oct 2012 21:01:30 +0900 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068CC6C.50001@ninjabadger.net> <50694CDF.8000606@necom830.hpcl.titech.ac.jp> <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> Message-ID: <5069861A.7020405@necom830.hpcl.titech.ac.jp> tom at ninjabadger.net wrote: >> It depends on distance between senders and receivers. >> >> However, at certain distance it becomes impossible to use >> efficient (w.r.t. bits per symbol) encoding, because of >> noise of repeated EDFA amplification. > > <500km not enough? > > https://www.de-cix.net/news-events/latest-news/news/article/de-cix-chooses-adva-optical-networkings-100g-metro-solution/ As it says: ADVA Optical Networking's 100G Metro solution is built on 4x28G direct detection technology and I wrote: Still, for 100GE, under some circumstances, 100GE with 4*25G may become less expensive than 10*10GE. 100GE over 500km could be fine. >> For 50Gbps lane, it becomes even harder and, for 100Gbps lane, >> it will likely to be impossible. > > Tell this to Ciena... ;) > > If you can afford Wave Logic 3 interfaces for your Nortel^WCiena 6500's, > you'll find some pretty impressive things are actually possible, > including 100G per 100GHz guide over very large distances (think > Atlantic-large). I'm afraid it uses 8 or 4 lanes. > Coherence appears to be the secret sauce in pushing the SnR boundaries, Just +3db, which is already counted, nothing more than that. >> http://www.peering-forum.eu/assets/presentations2012/JunpierEPF7.pdf >> >> But, it does not say much about >100G. > > Yes, that is the one. Slide #11 is the one I'm referring to, 'Projection > of Form Factor Evolution to 400G', which is relevant to the discussion > on optic densities and the push above 100G. As I wrote from the beginning that: (if same plug and cable are used both for 100GE and 10*10GE). physical form factors can be identical between 100GE (10*10G) and 10*10GE. Thus, the point of the slide #11 is not a valid counter argument against my point that trunked 40*10GE or 16*25GE is no worse than actually trunked 400GE with 40*10G or 16*25G. While slide #12 mentions 50Gbps per lane, it is too often impossible to be as practical as the Ethernet today. Masataka Ohta From aaron.glenn at gmail.com Mon Oct 1 12:11:33 2012 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Mon, 1 Oct 2012 16:11:33 +0400 Subject: RFC becomes Visio In-Reply-To: <50661D9F.3040008@thebaughers.com> References: <5065E7AE.7080504@ttec.com> <50661D9F.3040008@thebaughers.com> Message-ID: On Sat, Sep 29, 2012 at 1:58 AM, Jason Baugher wrote: > All they know is a consultant told them they needed to "do BGP" > with their ISP? what kind of consultant throws away the great billable hours that "design, configure, deploy, and test BGP session(s)" gives?! pretty sure I lived on setting up BGP sessions exclusively in '09... silly From shopik at inblock.ru Mon Oct 1 14:40:02 2012 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 01 Oct 2012 18:40:02 +0400 Subject: RFC becomes Visio In-Reply-To: <5065E9F9.9080809@rollernet.us> References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> Message-ID: On 28/09/12 22:18, Seth Mattinen wrote: > Hand draw two squares, label them "our AS" and "your AS" with a line > between them labeled "GigE". Bonus points for pencil. Don't forget have coffee mug stamp otherwise its unofficial diagram From source_route at yahoo.com Mon Oct 1 15:05:39 2012 From: source_route at yahoo.com (Philip Lavine) Date: Mon, 1 Oct 2012 08:05:39 -0700 (PDT) Subject: Centurylink has eyes for TWTC Message-ID: <1349103939.45939.YahooMailNeo@web121702.mail.ne1.yahoo.com> Another merger? I guess MABell is not to far away. From andreas at livejournalinc.com Mon Oct 1 19:47:16 2012 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 1 Oct 2012 12:47:16 -0700 Subject: So what's the deal with 10Gbase-T Message-ID: Hey guys, Does anyone here have experience running copper 10Gbase-T networks? It seems like the standard just died out. For us it would make a lot of sense for our applications -- even if throughput and latency aren't as great. If anyone out there knows of any *copper* 10 gig-t switches (48 port?), I'd be interested to hear your experiences. I can't seem to find any high-density ones from major vendors. Thanks, Andreas From kenneth.mcrae at dreamhost.com Mon Oct 1 19:53:55 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Mon, 1 Oct 2012 12:53:55 -0700 Subject: So what's the deal with 10Gbase-T In-Reply-To: References: Message-ID: Check out the Force 10 S4810 switch. On Mon, Oct 1, 2012 at 12:47 PM, Andreas Echavez wrote: > Hey guys, > > Does anyone here have experience running copper 10Gbase-T networks? It > seems like the standard just died out. For us it would make a lot of sense > for our applications -- even if throughput and latency aren't as great. If > anyone out there knows of any *copper* 10 gig-t switches (48 port?), I'd be > interested to hear your experiences. I can't seem to find any high-density > ones from major vendors. > > Thanks, > Andreas > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From nanog at jima.tk Mon Oct 1 19:58:38 2012 From: nanog at jima.tk (Jima) Date: Mon, 1 Oct 2012 13:58:38 -0600 (MDT) Subject: So what's the deal with 10Gbase-T In-Reply-To: References: Message-ID: <45308.2001:49f0:a057:0:f0da:c1ee:43f3:e40d.1349121518.squirrel@laughton.us> > Does anyone here have experience running copper 10Gbase-T networks? It > seems like the standard just died out. For us it would make a lot of sense > for our applications -- even if throughput and latency aren't as great. If > anyone out there knows of any *copper* 10 gig-t switches (48 port?), I'd > be > interested to hear your experiences. I can't seem to find any high-density > ones from major vendors. Is there something unique about your environment that wouldn't allow you to use 10gbit SFP+-based switches with DAC (Direct Attach Copper) cables? Those seem fairly well supported. Jima From andreas at livejournalinc.com Mon Oct 1 20:10:38 2012 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 1 Oct 2012 13:10:38 -0700 Subject: So what's the deal with 10Gbase-T In-Reply-To: <5069f62e.842f320a.1ea1.ffffee0eSMTPIN_ADDED@mx.google.com> References: <5069f62e.842f320a.1ea1.ffffee0eSMTPIN_ADDED@mx.google.com> Message-ID: Mostly backwards compatibility; simplicity. We're planning for some super-high-density virtualization/storage projects mixed in with lower bandwidth gear, and sticking to one type of cable for everything would be convenient. I thought DAC had some distance limitations as well. This is all speculation though, I don't have any personal experience with the 10Gbase-T stuff either. I have no idea what to expect performance-wise. -A On Mon, Oct 1, 2012 at 12:58 PM, Jima wrote: > > Does anyone here have experience running copper 10Gbase-T networks? It > > seems like the standard just died out. For us it would make a lot of > sense > > for our applications -- even if throughput and latency aren't as great. > If > > anyone out there knows of any *copper* 10 gig-t switches (48 port?), I'd > > be > > interested to hear your experiences. I can't seem to find any > high-density > > ones from major vendors. > > Is there something unique about your environment that wouldn't allow you > to use 10gbit SFP+-based switches with DAC (Direct Attach Copper) cables? > Those seem fairly well supported. > > Jima > > > From nanog at jima.tk Mon Oct 1 20:32:56 2012 From: nanog at jima.tk (Jima) Date: Mon, 1 Oct 2012 14:32:56 -0600 (MDT) Subject: So what's the deal with 10Gbase-T In-Reply-To: References: <5069f62e.842f320a.1ea1.ffffee0eSMTPIN_ADDED@mx.google.com> Message-ID: <46422.2001:49f0:a057:0:f0da:c1ee:43f3:e40d.1349123576.squirrel@laughton.us> Gotcha. With SFP+ I think the only nod to backward compatibility would be 1gbit RJ-45 SFPs, which can get a little spendy in large numbers (although so can DACs). As for distance, I admit I haven't encountered any DACs longer than 15 meters (~49 feet) -- not that I'm positive they don't exist. Jima On Mon, Oct 1, 2012 at 2:10pm, Andreas Echavez wrote: > Mostly backwards compatibility; simplicity. We're planning for some > super-high-density virtualization/storage projects mixed in with lower > bandwidth gear, and sticking to one type of cable for everything would be > convenient. I thought DAC had some distance limitations as well. > > This is all speculation though, I don't have any personal experience with > the 10Gbase-T stuff either. I have no idea what to expect > performance-wise. > > -A > > On Mon, Oct 1, 2012 at 12:58 PM, Jima wrote: > >> > Does anyone here have experience running copper 10Gbase-T networks? It >> > seems like the standard just died out. For us it would make a lot of >> sense >> > for our applications -- even if throughput and latency aren't as >> great. >> If >> > anyone out there knows of any *copper* 10 gig-t switches (48 port?), >> I'd >> > be >> > interested to hear your experiences. I can't seem to find any >> high-density >> > ones from major vendors. >> >> Is there something unique about your environment that wouldn't allow >> you >> to use 10gbit SFP+-based switches with DAC (Direct Attach Copper) >> cables? >> Those seem fairly well supported. >> >> Jima >> >> >> > From mark at viviotech.net Mon Oct 1 21:11:54 2012 From: mark at viviotech.net (Mark Keymer) Date: Mon, 01 Oct 2012 14:11:54 -0700 Subject: Data Center Flooring Message-ID: <506A071A.5010807@viviotech.net> We recently took possession of a building which part of it was used for a teleco room by a Cellular company. The floor looks like crap. So we were thinking about maybe just putting another new flooring on top. Currently it has some type of tile looking flooring. I have been told the the entry way into the building is Anti-static. However No idea on the actual data center flooring. I know in the past there have been talks about datacenter flooring. (Even Carpet if I recall). What I am wondering is does the actual datacenter flooring need to be like Static Dissipating. (Found something that does that for about $10.00 a Sqr foot). Or can it just be non static generating or like non conducting. Not quite sure the wording to use here. Any thoughts on this would be appreciated on or off the list. Sincerely, -- Mark Keymer From WTribble at sterneagee.com Mon Oct 1 21:12:33 2012 From: WTribble at sterneagee.com (Tribble, Wesley) Date: Mon, 1 Oct 2012 16:12:33 -0500 Subject: So what's the deal with 10Gbase-T In-Reply-To: <46422.2001:49f0:a057:0:f0da:c1ee:43f3:e40d.1349123576.squirrel@laughton.us> References: <5069f62e.842f320a.1ea1.ffffee0eSMTPIN_ADDED@mx.google.com> <46422.2001:49f0:a057:0:f0da:c1ee:43f3:e40d.1349123576.squirrel@laughton.us> Message-ID: 10Gbase-T doesn't make much sense for a new virtual environment. Once you factor in the cost of the cabling and power, you probably would have been better off with DAC or FET interconnects. Also 10Gbase-T does not necessarily work with Legacy wiring, depending upon how it was run. Large bundles of wire cause crosstalk issues on legacy cabling, this is the reason for large jackets on 6A. http://www.siemon.com/us/learning/alien-crosstalk-guide.asp I'm not saying it won't work for your scenario as I am not familiar with your environment, just keep it in mind that with most environments, DAC is a cheaper and provides better latency for your storage traffic. -----Original Message----- From: Jima [mailto:nanog at jima.tk] Sent: Monday, October 01, 2012 3:33 PM To: nanog at nanog.org Subject: Re: So what's the deal with 10Gbase-T Gotcha. With SFP+ I think the only nod to backward compatibility would be 1gbit RJ-45 SFPs, which can get a little spendy in large numbers (although so can DACs). As for distance, I admit I haven't encountered any DACs longer than 15 meters (~49 feet) -- not that I'm positive they don't exist. Jima On Mon, Oct 1, 2012 at 2:10pm, Andreas Echavez wrote: > Mostly backwards compatibility; simplicity. We're planning for some > super-high-density virtualization/storage projects mixed in with lower > bandwidth gear, and sticking to one type of cable for everything would > be convenient. I thought DAC had some distance limitations as well. > > This is all speculation though, I don't have any personal experience > with the 10Gbase-T stuff either. I have no idea what to expect > performance-wise. > > -A > > On Mon, Oct 1, 2012 at 12:58 PM, Jima wrote: > >> > Does anyone here have experience running copper 10Gbase-T networks? >> > It seems like the standard just died out. For us it would make a >> > lot of >> sense >> > for our applications -- even if throughput and latency aren't as >> great. >> If >> > anyone out there knows of any *copper* 10 gig-t switches (48 >> > port?), >> I'd >> > be >> > interested to hear your experiences. I can't seem to find any >> high-density >> > ones from major vendors. >> >> Is there something unique about your environment that wouldn't allow >> you to use 10gbit SFP+-based switches with DAC (Direct Attach Copper) >> cables? >> Those seem fairly well supported. >> >> Jima >> >> >> > ************************************************************************************************** Sterne Agee Group, Inc. and its subsidiaries request that you do not transmit orders and instructions regarding your Sterne Agee account by e-mail. Transactional details do not supersede normal trade confirmations or statements. The information contained in this transmission is privileged and confidential. It is intended for the use of the individual or entity named above. The information contained herein is based on sources we believe reliable but is not considered all-inclusive. Opinions are our current opinions only and are subject to change without notice. Offerings are subject to prior sale and/or change in price. Prices, quotes, rates and yields are subject to change without notice. Sterne Agee & Leach, Inc. member FINRA and SIPC, is a registered broker-dealer subsidiary of Sterne Agee Group, Inc. Generally, investments are NOT FDIC INSURED, NOT BANK GUARANTEED, and MAY LOSE VALUE. Please contact your Financial Advisor with information regarding specific investments. Sterne Agee reserves the right to monitor all electronic correspondence. ************************************************************************************************** From mikevs at xs4all.net Mon Oct 1 21:27:55 2012 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Mon, 1 Oct 2012 23:27:55 +0200 Subject: So what's the deal with 10Gbase-T In-Reply-To: Message-ID: <201210012127.q91LRtS5016977@xs8.xs4all.nl> In article , Andreas Echavez wrote: >Does anyone here have experience running copper 10Gbase-T networks? It >seems like the standard just died out. Well, our new supermicro servers come with 10Gbase-T standard on the motherboard. >For us it would make a lot of sense >for our applications -- even if throughput and latency aren't as great. If >anyone out there knows of any *copper* 10 gig-t switches (48 port?) Arista, http://www.aristanetworks.com/ Mike. From streiner at cluebyfour.org Mon Oct 1 21:38:18 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 1 Oct 2012 17:38:18 -0400 (EDT) Subject: Data Center Flooring In-Reply-To: <506A071A.5010807@viviotech.net> References: <506A071A.5010807@viviotech.net> Message-ID: On Mon, 1 Oct 2012, Mark Keymer wrote: > I know in the past there have been talks about datacenter flooring. (Even > Carpet if I recall). What I am wondering is does the actual datacenter > flooring need to be like Static Dissipating. (Found something that does that > for about $10.00 a Sqr foot). Or can it just be non static generating or like > non conducting. Not quite sure the wording to use here. We normally spec out VCT static dissipative floor tiling for our technical spaces that are not on raised flooring. jms From dstorandt at teljet.com Mon Oct 1 21:44:31 2012 From: dstorandt at teljet.com (David Storandt) Date: Mon, 1 Oct 2012 17:44:31 -0400 Subject: Data Center Flooring In-Reply-To: References: <506A071A.5010807@viviotech.net> Message-ID: If you are thinking of VCT, try stained+polished concrete. Naturally grounded for low-humidity spaces, supports >3500PSI point loads, and much better looking. >> I know in the past there have been talks about datacenter flooring. (Even >> Carpet if I recall). What I am wondering is does the actual datacenter >> flooring need to be like Static Dissipating. (Found something that does >> that for about $10.00 a Sqr foot). Or can it just be non static generating >> or like non conducting. Not quite sure the wording to use here. > From ghira at mistral.co.uk Tue Oct 2 00:51:28 2012 From: ghira at mistral.co.uk (Adam Atkinson) Date: Tue, 02 Oct 2012 01:51:28 +0100 Subject: So what's the deal with 10Gbase-T In-Reply-To: References: Message-ID: <506A3A90.8040705@mistral.co.uk> Andreas Echavez wrote: > Hey guys, > > Does anyone here have experience running copper 10Gbase-T networks? Yes. > It > seems like the standard just died out. For us it would make a lot of sense > for our applications -- even if throughput and latency aren't as great. If > anyone out there knows of any *copper* 10 gig-t switches (48 port?), I'd be > interested to hear your experiences. I can't seem to find any high-density > ones from major vendors. Well, I'm not sure about 48 port. I have several of these: http://www.extremenetworks.com/products/summit-x650.aspx which are 24 port 10Gbase-T switches. I got them in.. late 2008? 2009? Not sure offhand. From the same manufacturer there's the more recent http://www.extremenetworks.com/products/summit-x670.aspx also 1U, which appears to be 48 port or more and to have a copper version but I've not actually seen one. And both models are stackable. From betty at newnog.org Tue Oct 2 01:37:19 2012 From: betty at newnog.org (Betty Burke ) Date: Mon, 1 Oct 2012 21:37:19 -0400 Subject: [NANOG-announce] NANOG Election Update Message-ID: Colleagues: The final stages of our annual NANOG Election process is underway. Today, October 1, 2012 is the last day to submit nominations to the NANOG Board of Directors. The NANOG Board is responsible for ensuring NANOG operates in a way that is consistent with our Bylaws, financially sound, and helps to ensure NANOG is an organization that meets the needs of the internet community and the NANOG Members. Please consider a self-nomination, or a nomination of someone you feel would be a strong candidate. Refer to http://www.nanog.org/governance/elections/2012elections/ for complete information. If you are not yet a member of NANOG, or have not yet renewed your membership, please consider doing so. As of this writing, NANOG has 315 members! There are additional benefits to membership, however, the most important is the control members have through their votes. Only members can vote, and are eligible to serve on the NANOG Board and NANOG Committees; thus helping to decide the direction of NANOG. Refer to http://www.nanog.org/membership_main.html for complete membership information. I hope you will consider becoming part of the process! Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From repstein at hostleasing.net Tue Oct 2 02:36:59 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Mon, 01 Oct 2012 22:36:59 -0400 Subject: [NANOG-announce] Maintenance Notification for Wednesday, October 3rd, 2012 at 11am Eastern Message-ID: Dear Colleagues, On Wednesday, October 3rd, 2012 at 11am Eastern Time, access to NANOG Meeting Registration, submissions to PC.NANOG.ORG, and access to the membership portal will be unavailable for 30-60 minutes. Should you have any questions, please feel free to contact the NANOG Communications Committee for more details, admins at nanog.org. Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From eugen at leitl.org Tue Oct 2 06:21:41 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 2 Oct 2012 08:21:41 +0200 Subject: [liberationtech] The Hidden Internet of Iran: Private Address Allocations on a National Network Message-ID: <20121002062141.GP9750@leitl.org> Sounds just like CGN. ----- Forwarded message from Collin Anderson ----- From: Collin Anderson Date: Mon, 1 Oct 2012 15:06:34 -0400 To: liberationtech at lists.stanford.edu Subject: [liberationtech] The Hidden Internet of Iran: Private Address Allocations on a National Network Reply-To: liberationtech Libtech, I want to share a working paper of mine that was posted to arXiv last night. This is part of an ongoing effort to start producing verifiable dataset on how Iran's Internet works, and was a surprising discovery that I wanted to share with everyone else -- in lead up to a broader output *The Hidden Internet of Iran: Private Address Allocations on a National Network* While funding agencies have provided substantial support for the developers and vendors of services that facilitate the unfettered flow of information through the Internet, little consolidated knowledge exists on the basic communications network infrastructure of the Islamic Republic of Iran. In the absence open access and public data, rumors and fear have reigned supreme. During provisional research on the country's censorship regime, we found initial indicators that telecommunications entities in Iran allowed private addresses to route domestically, whether intentionally or unintentionally, creating a hidden network only reachable within the country. Moreover, records such as DNS entries lend evidence of a 'dual stack' approach, wherein servers are assigned a domestic IP addresses, in addition to a global one. Despite the clear political implications of the claim we put forward, particularly in light of rampant speculation regarding the mandate of Article 46 of the 'Fifth Five Year Development Plan' to establish a "national information network," we refrain from hypothesizing the purpose of this structure. In order to solicit critical feedback for future research, we outline our initial findings and attempt to demonstrate that the matter under contention is a nation-wide phenomenom that warrants broader attention. http://arxiv.org/abs/1209.6398 Cordially, Collin -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- From randy at psg.com Tue Oct 2 08:40:58 2012 From: randy at psg.com (Randy Bush) Date: Tue, 02 Oct 2012 09:40:58 +0100 Subject: [liberationtech] The Hidden Internet of Iran: Private Address Allocations on a National Network In-Reply-To: <20121002062141.GP9750@leitl.org> References: <20121002062141.GP9750@leitl.org> Message-ID: > Sounds just like CGN. at least one large iranian network build failed to get in the ripe/ncc open pool sale when the lights went out. randy From alex at corp.nac.net Tue Oct 2 11:36:03 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 2 Oct 2012 07:36:03 -0400 Subject: Data Center Flooring In-Reply-To: <506A071A.5010807@viviotech.net> References: <506A071A.5010807@viviotech.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81ACFE24BC9@EXCHMBX.hq.nac.net> We have operated with several types of floor in four locations over the last 15 years (Raised, VCT, painted, and polished concrete). Personally, I like the look of the polished concrete the best. It's relatively cheap and easy to do. Epoxy and VCT tend to get hurt over time and require considerably maintenance. If you want any pics, let me know. >From a static electricity aspect, we have never had a problem with any flooring ever - that is more about humidity level and proper grounding. -----Original Message----- From: Mark Keymer [mailto:mark at viviotech.net] Sent: Monday, October 01, 2012 5:12 PM To: North American Network Operators' Group Subject: Data Center Flooring We recently took possession of a building which part of it was used for a teleco room by a Cellular company. The floor looks like crap. So we were thinking about maybe just putting another new flooring on top. Currently it has some type of tile looking flooring. I have been told the the entry way into the building is Anti-static. However No idea on the actual data center flooring. I know in the past there have been talks about datacenter flooring. (Even Carpet if I recall). What I am wondering is does the actual datacenter flooring need to be like Static Dissipating. (Found something that does that for about $10.00 a Sqr foot). Or can it just be non static generating or like non conducting. Not quite sure the wording to use here. Any thoughts on this would be appreciated on or off the list. Sincerely, -- Mark Keymer From gourmetcisco at hotmail.com Tue Oct 2 12:35:04 2012 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Tue, 2 Oct 2012 08:35:04 -0400 Subject: Cost of fiber run between neighbouring office buildings Message-ID: Hi folks, I wonder if I can tap into some knowledge on the list and ask for ballpark figures on how much it would normally cost to run 2 fiber cables between 2 adjacent office buildings. I have a quote from a contractor, and I want to make sure i'm not getting totally fleeced. The conduit is in place between the buildings. The work entails: - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables - Distance of run is approx 520 meters - Total of 8 terminations (2 strands on each end of links) - Testing, documentation Thanks, Hank From mark at viviotech.net Tue Oct 2 12:58:47 2012 From: mark at viviotech.net (Mark Keymer) Date: Tue, 02 Oct 2012 05:58:47 -0700 Subject: Data Center Flooring In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81ACFE24BC9@EXCHMBX.hq.nac.net> References: <506A071A.5010807@viviotech.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81ACFE24BC9@EXCHMBX.hq.nac.net> Message-ID: <506AE507.7020003@viviotech.net> Thank you for the information, both on and off-list. It has been very helpful. Also it looks likes the current tiles are VCT so no Asbestos currently. Sincerely, Mark Keymer On 10/2/2012 4:36 AM, Alex Rubenstein wrote: > We have operated with several types of floor in four locations over the last 15 years (Raised, VCT, painted, and polished concrete). > > Personally, I like the look of the polished concrete the best. It's relatively cheap and easy to do. Epoxy and VCT tend to get hurt over time and require considerably maintenance. If you want any pics, let me know. > > From a static electricity aspect, we have never had a problem with any flooring ever - that is more about humidity level and proper grounding. > > > > > -----Original Message----- > From: Mark Keymer [mailto:mark at viviotech.net] > Sent: Monday, October 01, 2012 5:12 PM > To: North American Network Operators' Group > Subject: Data Center Flooring > > We recently took possession of a building which part of it was used for a teleco room by a Cellular company. The floor looks like crap. So we were thinking about maybe just putting another new flooring on top. > Currently it has some type of tile looking flooring. I have been told the the entry way into the building is Anti-static. However No idea on the actual data center flooring. > > I know in the past there have been talks about datacenter flooring. > (Even Carpet if I recall). What I am wondering is does the actual datacenter flooring need to be like Static Dissipating. (Found something that does that for about $10.00 a Sqr foot). Or can it just be non static generating or like non conducting. Not quite sure the wording to use here. > > Any thoughts on this would be appreciated on or off the list. > > Sincerely, > > -- > Mark Keymer From nick at foobar.org Tue Oct 2 13:01:37 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Oct 2012 14:01:37 +0100 Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: References: Message-ID: <506AE5B1.5030504@foobar.org> On 02/10/2012 13:35, Hank Disuko wrote: > - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables > - Distance of run is approx 520 meters For that length, go with single-mode. 10G-LR will happily run on 10km of SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant like this is totally pointless. Using MMF for anything outside your cabinet / small cage is creating a legacy deployment on day 1 which will bite you in future years. To answer the question you asked: if the ducts are already in place and you're just pulling fibre through, you should have a breakdown in terms of # of terminations + the manpower required to handle the pull + cable finishing. I.e. it shouldn't be very much. If you need ducting laid or if your existing ducting is in poor shape, that's a different issue. Nick From lathama at gmail.com Tue Oct 2 13:07:00 2012 From: lathama at gmail.com (Andrew Latham) Date: Tue, 2 Oct 2012 09:07:00 -0400 Subject: Data Center Flooring In-Reply-To: <506AE507.7020003@viviotech.net> References: <506A071A.5010807@viviotech.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81ACFE24BC9@EXCHMBX.hq.nac.net> <506AE507.7020003@viviotech.net> Message-ID: On Tue, Oct 2, 2012 at 8:58 AM, Mark Keymer wrote: > Thank you for the information, both on and off-list. > > It has been very helpful. > > Also it looks likes the current tiles are VCT so no Asbestos currently. > > Sincerely, > > Mark Keymer > > > On 10/2/2012 4:36 AM, Alex Rubenstein wrote: >> >> We have operated with several types of floor in four locations over the >> last 15 years (Raised, VCT, painted, and polished concrete). >> >> Personally, I like the look of the polished concrete the best. It's >> relatively cheap and easy to do. Epoxy and VCT tend to get hurt over time >> and require considerably maintenance. If you want any pics, let me know. >> >> From a static electricity aspect, we have never had a problem with any >> flooring ever - that is more about humidity level and proper grounding. >> >> >> >> >> -----Original Message----- >> From: Mark Keymer [mailto:mark at viviotech.net] >> Sent: Monday, October 01, 2012 5:12 PM >> To: North American Network Operators' Group >> Subject: Data Center Flooring >> >> We recently took possession of a building which part of it was used for a >> teleco room by a Cellular company. The floor looks like crap. So we were >> thinking about maybe just putting another new flooring on top. >> Currently it has some type of tile looking flooring. I have been told the >> the entry way into the building is Anti-static. However No idea on the >> actual data center flooring. >> >> I know in the past there have been talks about datacenter flooring. >> (Even Carpet if I recall). What I am wondering is does the actual >> datacenter flooring need to be like Static Dissipating. (Found something >> that does that for about $10.00 a Sqr foot). Or can it just be non static >> generating or like non conducting. Not quite sure the wording to use here. >> >> Any thoughts on this would be appreciated on or off the list. >> >> Sincerely, >> >> -- >> Mark Keymer If I may give a +1 to the concrete. Polishing is part of the install and often the harsh surface is intended for adhesives or shoe/tire grip. As mentioned the reduced cost is also great. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From jra at baylink.com Tue Oct 2 14:49:54 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 2 Oct 2012 10:49:54 -0400 (EDT) Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: Message-ID: <29296373.27705.1349189394872.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Hank Disuko" > I wonder if I can tap into some knowledge on the list and ask for > ballpark figures on how much it would normally cost to run 2 fiber > cables between 2 adjacent office buildings. I have a quote from a > contractor, and I want to make sure i'm not getting totally fleeced. > > The conduit is in place between the buildings. > > The work entails: > > - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser > Ultra-Fox Fiber cables > - Distance of run is approx 520 meters > - Total of 8 terminations (2 strands on each end of links) > - Testing, documentation I had one 6-strand direct burial run through as-had 4-inch pvc between two of my buildings about 4 years ago, IIRC, the final price was on the order of $1300 for about a 300m run; terminated in ST boxes at each end I don't recall if he furnished the patches or if we bought them ourselves; I think the latter. They had to split the pipe halfway and put a pullbox in/over. What did they quote you? PS: protip: split those 2+2 instead of 3+1 for better redundancy. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ghankins at mindspring.com Tue Oct 2 14:54:41 2012 From: ghankins at mindspring.com (Greg Hankins) Date: Tue, 2 Oct 2012 10:54:41 -0400 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <5069861A.7020405@necom830.hpcl.titech.ac.jp> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068CC6C.50001@ninjabadger.net> <50694CDF.8000606@necom830.hpcl.titech.ac.jp> <90d6f59c19749e33362af6ac82023edf@ninjabadger.net> <5069861A.7020405@necom830.hpcl.titech.ac.jp> Message-ID: <20121002145441.GA16364@brocade.com> Several good presentations were given at the IEEE meeting in Geneva last week about why we should do 400 GbE and not TbE. You can find them here: http://www.ieee802.org/3/ad_hoc/hse/public/12_09/index.shtml . Greg -- Greg Hankins From eugen at leitl.org Tue Oct 2 15:58:13 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 2 Oct 2012 17:58:13 +0200 Subject: US government gets an "F" for IPv6 Internet make-over Message-ID: <20121002155813.GV9750@leitl.org> ----- Forwarded message from "Steven J. Vaughan-Nichols" ----- From: "Steven J. Vaughan-Nichols" Date: Tue, 02 Oct 2012 11:24:36 -0400 To: ipv6-ops at lists.cluenet.de Subject: US government gets an "F" for IPv6 Internet make-over Organization: Vaughan-Nichols & Associates X-Mailer: Evolution 3.2.3-0ubuntu6 Reply-To: "Steven J. Vaughan-Nichols" http://www.zdnet.com/us-government-gets-an-f-for-ipv6-internet-make-over-7000005055/ And, here's what I found when all was said and done after 9/30. Steven -- Steven J. Vaughan-Nichols Contributing Editor, CBS/ZDNet: http://www.zdnet.com/meet-the-team/us/steven.j.vaughan-nichols/ Columnist, ComputerWorld: http://www.computerworld.com/s/columnist/9000320/Steven+J.+Vaughan-Nichols Columnist, NetworkWorld: http://www.networkworld.com/community/blog/26145 QOTD: "For every complex problem there is an answer that is clear, simple, and wrong."--H.L. Mencken ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From randy at psg.com Tue Oct 2 16:01:55 2012 From: randy at psg.com (Randy Bush) Date: Tue, 02 Oct 2012 17:01:55 +0100 Subject: US government gets an "F" for IPv6 Internet make-over In-Reply-To: <20121002155813.GV9750@leitl.org> References: <20121002155813.GV9750@leitl.org> Message-ID: rair.psg.com:/Users/randy> host leitl.org leitl.org has address 85.10.225.64 leitl.org mail is handled by 10 v64.ativel.com. rair.psg.com:/Users/randy> host v64.ativel.com v64.ativel.com has address 85.10.225.64 v64.ativel.com mail is handled by 10 v64.ativel.com.ativel.com. time to stop shit-stirring and get to work, eh? rand From me at anuragbhatia.com Mon Oct 1 19:03:07 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 2 Oct 2012 00:33:07 +0530 Subject: Strange MTR output - reversed/mixed/noisy Message-ID: Hello everyone, Sometimes back I changed my home's router. Right from that time I am getting very strange MTR output. It starts like normal and as soon as the trace is complete, it starts reversing and then I see 2nd hop replaced by 2nd last, and whole output clogs up badly. E.g here's an output with my Europe based server (see the embedded picture): [image: Inline image 1] Some observations so far: 1. Traceroute works fine 2. UDP based MTR works fine 3. Many times mtr output is OK for local servers with few hops and low latency. I have a feeling here that somehow TCP packets are returning late/delayed and the there's some mis-count or so. For ICMP or UDP it works well and for low latency near servers also it is mostly OK. Anyone having any idea what could be causing this strange output? Thanks! -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ -------------- next part -------------- A non-text attachment was scrubbed... Name: mtr.png Type: image/png Size: 111800 bytes Desc: not available URL: From brian at aereo.com Mon Oct 1 22:27:00 2012 From: brian at aereo.com (Brian Loveland) Date: Mon, 1 Oct 2012 18:27:00 -0400 Subject: So what's the deal with 10Gbase-T In-Reply-To: <201210012127.q91LRtS5016977@xs8.xs4all.nl> References: <201210012127.q91LRtS5016977@xs8.xs4all.nl> Message-ID: Also, IBM G8364 (uses Broadcom Trident merchant silicon). I believe the Force10 S4810 (also Broadcom Trident) is only SFP+? Intel will force 10GBASE-T on all of us since they can make it backwards compatible with 1000BASE-T. I think this will make the technology take off over the next year or so. Been very happy running SFP+ twinax but sometimes I do wish I could go further than 5/7/8.5 meters. On Mon, Oct 1, 2012 at 5:27 PM, Miquel van Smoorenburg wrote: > In article < > CAJ0Nkqgy2x9pUg26CcjcHwDQSMY24f1U0RWmhF2PoH2eHih2zg at mail.gmail.com>, > Andreas Echavez wrote: > >Does anyone here have experience running copper 10Gbase-T networks? It > >seems like the standard just died out. > > Well, our new supermicro servers come with 10Gbase-T standard on > the motherboard. > > >For us it would make a lot of sense > >for our applications -- even if throughput and latency aren't as great. If > >anyone out there knows of any *copper* 10 gig-t switches (48 port?) > > Arista, http://www.aristanetworks.com/ > > Mike. > > From brian at aereo.com Mon Oct 1 22:37:30 2012 From: brian at aereo.com (Brian Loveland) Date: Mon, 1 Oct 2012 18:37:30 -0400 Subject: So what's the deal with 10Gbase-T In-Reply-To: References: <201210012127.q91LRtS5016977@xs8.xs4all.nl> Message-ID: Sorry, that is IBM G8264T. G8316 is the 16x40G version. On Mon, Oct 1, 2012 at 6:27 PM, Brian Loveland wrote: > Also, IBM G8364 (uses Broadcom Trident merchant silicon). > > I believe the Force10 S4810 (also Broadcom Trident) is only SFP+? > > Intel will force 10GBASE-T on all of us since they can make it backwards > compatible with 1000BASE-T. I think this will make the technology take off > over the next year or so. > > Been very happy running SFP+ twinax but sometimes I do wish I could go > further than 5/7/8.5 meters. > > > On Mon, Oct 1, 2012 at 5:27 PM, Miquel van Smoorenburg wrote: > >> In article < >> CAJ0Nkqgy2x9pUg26CcjcHwDQSMY24f1U0RWmhF2PoH2eHih2zg at mail.gmail.com>, >> Andreas Echavez wrote: >> >Does anyone here have experience running copper 10Gbase-T networks? It >> >seems like the standard just died out. >> >> Well, our new supermicro servers come with 10Gbase-T standard on >> the motherboard. >> >> >For us it would make a lot of sense >> >for our applications -- even if throughput and latency aren't as great. >> If >> >anyone out there knows of any *copper* 10 gig-t switches (48 port?) >> >> Arista, http://www.aristanetworks.com/ >> >> Mike. >> >> > From groupstudytac at gmail.com Tue Oct 2 13:00:37 2012 From: groupstudytac at gmail.com (groupstudytac groupstudytac) Date: Tue, 2 Oct 2012 14:00:37 +0100 Subject: IP traffic trend analysis Message-ID: Hi All , What tool do you use in house for Trend anaylsis of Aggregate IP traffic or should i say what is the best way to carry out trend analysis of the aggregate IP traffic throughput in a carrier network. Rgds G From bhm at ufl.edu Tue Oct 2 14:21:19 2012 From: bhm at ufl.edu (Bruce H McIntosh) Date: Tue, 02 Oct 2012 10:21:19 -0400 Subject: IPv6 Ignorance In-Reply-To: References: <20120917233210.61755.qmail@joyce.lan> <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> Message-ID: <1349187679.14686.4.camel@highlands> On Sat, 2012-09-29 at 16:53 +1000, Jason Leschnik wrote: > To address everything in the Universe wouldn't you then get stuck in > some kinda of loop of having to address the matter that is used by the > addresses... i.e. to address everything in the Universe you need more > matter than the Universe? > > *brain* pop You just have to have a mechanism to NAT the quarks... or wait 'til IPv8 comes out. 512 bits should be big enough to allow hierarchical routing for alternate universes, yes? -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida CNS/Network Services 352-273-1066 From rs at seastrom.com Tue Oct 2 16:48:33 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 02 Oct 2012 12:48:33 -0400 Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: <506AE5B1.5030504@foobar.org> (Nick Hilliard's message of "Tue, 02 Oct 2012 14:01:37 +0100") References: <506AE5B1.5030504@foobar.org> Message-ID: <86y5jox1jy.fsf@seastrom.com> Second what Nick said. Also, get quotes for double, quadruple, and more of the number of fibers you think you need today. If it makes economic sense to leave strands unterminated (coil neatly in the splice tray and have someone term later) by all means do it. Extra strands in the cable are almost free compared to the labor to pull it in. -r Nick Hilliard writes: > On 02/10/2012 13:35, Hank Disuko wrote: >> - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables >> - Distance of run is approx 520 meters > > For that length, go with single-mode. 10G-LR will happily run on 10km of > SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant > like this is totally pointless. Using MMF for anything outside your > cabinet / small cage is creating a legacy deployment on day 1 which will > bite you in future years. > > To answer the question you asked: if the ducts are already in place and > you're just pulling fibre through, you should have a breakdown in terms of > # of terminations + the manpower required to handle the pull + cable > finishing. I.e. it shouldn't be very much. If you need ducting laid or if > your existing ducting is in poor shape, that's a different issue. > > Nick From cdel at firsthand.net Tue Oct 2 16:56:31 2012 From: cdel at firsthand.net (cdel.firsthand.net) Date: Tue, 2 Oct 2012 17:56:31 +0100 Subject: US government gets an "F" for IPv6 Internet make-over In-Reply-To: <20121002155813.GV9750@leitl.org> References: <20121002155813.GV9750@leitl.org> Message-ID: 20% for .gov .... Compared to .gov.uk and most of RoW that is outstanding progress. Kudos. I'd prefer to see serious lessons learned from those guys to help get the other 80% IPv6 visible in .gov and encourage other gov.cctlds to do likewise. Shouting Fail doesn't help anyone. Incidentally the deadline is useful. I found World IPv6 day in June 2011 helpful in concentrating my mind to get a bunch of domains that had stayed resolutely v4 only and their hosted services on v6 including local lSOC chapter and other community sites. Just in time is fine particularly as they remained up on v6 since. So no effort required for World IPv6 launch earlier this year. :-) So big tick to those .gov services now on v6. Christian de Larrinaga On 2 Oct 2012, at 16:58, Eugen Leitl wrote: > ----- Forwarded message from "Steven J. Vaughan-Nichols" ----- > > From: "Steven J. Vaughan-Nichols" > Date: Tue, 02 Oct 2012 11:24:36 -0400 > To: ipv6-ops at lists.cluenet.de > Subject: US government gets an "F" for IPv6 Internet make-over > Organization: Vaughan-Nichols & Associates > X-Mailer: Evolution 3.2.3-0ubuntu6 > Reply-To: "Steven J. Vaughan-Nichols" > > http://www.zdnet.com/us-government-gets-an-f-for-ipv6-internet-make-over-7000005055/ > > And, here's what I found when all was said and done after 9/30. > > Steven > > -- > Steven J. Vaughan-Nichols > Contributing Editor, CBS/ZDNet: http://www.zdnet.com/meet-the-team/us/steven.j.vaughan-nichols/ > Columnist, ComputerWorld: http://www.computerworld.com/s/columnist/9000320/Steven+J.+Vaughan-Nichols > Columnist, NetworkWorld: http://www.networkworld.com/community/blog/26145 > QOTD: "For every complex problem there is an answer that is clear, simple, and wrong."--H.L. Mencken > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > From walter.keen at rainierconnect.net Tue Oct 2 17:03:44 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Tue, 2 Oct 2012 10:03:44 -0700 (PDT) Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: <86y5jox1jy.fsf@seastrom.com> Message-ID: <1214515989.2096067.1349197424022.JavaMail.root@zimbra01.rainierconnect.net> Where I work for a local telecommunications provider, we will not run any fiber smaller than 24 strand, and these days that is a drop into a building. When talking about single mode fiber, the cost per foot difference in 2, 8, or even 24 strand is typically a matter of less than $1 per foot. Some of the prices I've seen lately on google indicate about $.4/ft for 2-strand, $.5/ft for 6-strand, and $1.8/ft for 24-strand It's all about the cost of getting it run by a contractor (which is typical if you have to get conduit installed, or run along telephone/power poles aerial) , unless you're in a position to do it yourself. You'd likely have to pay someone to terminate it into a patch panel for you, but it may be cheaper for them to do all strands at once as opposed to having them come back later. ----- Original Message ----- From: "Robert E. Seastrom" To: "Nick Hilliard" Cc: "NANOG" Sent: Tuesday, October 2, 2012 9:48:33 AM Subject: Re: Cost of fiber run between neighbouring office buildings Second what Nick said. Also, get quotes for double, quadruple, and more of the number of fibers you think you need today. If it makes economic sense to leave strands unterminated (coil neatly in the splice tray and have someone term later) by all means do it. Extra strands in the cable are almost free compared to the labor to pull it in. -r Nick Hilliard writes: > On 02/10/2012 13:35, Hank Disuko wrote: >> - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables >> - Distance of run is approx 520 meters > > For that length, go with single-mode. 10G-LR will happily run on 10km of > SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant > like this is totally pointless. Using MMF for anything outside your > cabinet / small cage is creating a legacy deployment on day 1 which will > bite you in future years. > > To answer the question you asked: if the ducts are already in place and > you're just pulling fibre through, you should have a breakdown in terms of > # of terminations + the manpower required to handle the pull + cable > finishing. I.e. it shouldn't be very much. If you need ducting laid or if > your existing ducting is in poor shape, that's a different issue. > > Nick From wsummers at deerfield.edu Tue Oct 2 17:05:06 2012 From: wsummers at deerfield.edu (Summers, William) Date: Tue, 2 Oct 2012 13:05:06 -0400 Subject: Cost of fiber run between neighbouring office buildings Message-ID: You can get a reasonable estimate by looking at a pre-terminated fiber for that distance. Add lineitems for termination boxes and labor 1-2 days labor for 2 techs. (If you email me I'll tell you the vendor I use for pre-terminated fiber, but searching should yield results). From repstein at hostleasing.net Tue Oct 2 17:21:35 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Tue, 02 Oct 2012 13:21:35 -0400 Subject: [NANOG-announce] List ID changed for NANOG mail list Message-ID: Greetings, A quick email to let folks know that we've changed the list ID to mailman.nanog.org. It was previously nanog.nanog.org. This notification is to alert you in case you need to modify your procmail filters. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From bill at herrin.us Tue Oct 2 17:49:15 2012 From: bill at herrin.us (William Herrin) Date: Tue, 2 Oct 2012 13:49:15 -0400 Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: <506AE5B1.5030504@foobar.org> References: <506AE5B1.5030504@foobar.org> Message-ID: On Tue, Oct 2, 2012 at 9:01 AM, Nick Hilliard wrote: > On 02/10/2012 13:35, Hank Disuko wrote: >> - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables >> - Distance of run is approx 520 meters > > For that length, go with single-mode. 10G-LR will happily run on 10km of > SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant > like this is totally pointless. Using MMF for anything outside your > cabinet / small cage is creating a legacy deployment on day 1 which will > bite you in future years. I second what Nick said. Single mode for anything longer than a few meters. *IF* you have existing conduit, consider just buying an AMP Lightcrimp Plus kit, picking up some single mode from ebay and doing it yourself. Each Lightcrimp Plus termination is expensive so you wouldn't want to use it for a large job or a large set of jobs, but they've reduced the difficulty level to about what you're used to for RJ45. You could end up in a break-even situation that leaves you with a tool set for next time. You can also buy pre-terminated fiber assembly with a pulling eye and cable netting at one end for pulling it through the conduit. But you'll probably have to go with new fiber; not much in the way of long preterminated cables show up in the used market. If you don't have conduit already, consider: Conduit requires trenching and repair of surfaces afterwards. Big dollars and God help you if you get an amateur because Home Depot doesn't stock the right pipe. Direct burial is cheaper for single installations but you have to keep paying the whole price if you add to it later. Worse really, because each new installation has to carefully avoid cutting the ones before. Conduit, once installed, can support lots of additional cable. Microduct is a happy medium between the two. It's about as easy to install as direct burial cable and once installed you can both blow new fiber through unused ducts and remove obsolete fiber from existing ducts. Microduct even installs well across roadways with a machine that looks like a four-foot circular saw. They can seal the road overtop with tar instead of having to patch or repave which is a major cost savings. Unlike conduit, microduct really only works for fiber. If you also want to run some copper lines, you can't do it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wsummers at deerfield.edu Tue Oct 2 18:14:09 2012 From: wsummers at deerfield.edu (Summers, William) Date: Tue, 2 Oct 2012 14:14:09 -0400 Subject: So what's the deal with 10Gbase-T Message-ID: We've been using IBM 10G switches (8124 and 8264) sfp varieties back when they were Blade Networks. Very good performance, cost, and support. The use of DACs/Twinax in our datacenters made our 10G overhaul budget work. From joly at punkcast.com Tue Oct 2 19:03:04 2012 From: joly at punkcast.com (Joly MacFie) Date: Tue, 2 Oct 2012 15:03:04 -0400 Subject: US government gets an "F" for IPv6 Internet make-over In-Reply-To: <20121002155813.GV9750@leitl.org> References: <20121002155813.GV9750@leitl.org> Message-ID: The ISOC Deploy 360 team has published some analysis at http://www.internetsociety.org/deploy360/blog/2012/09/with-september-30-deadline-looming-us-government-enables-ipv6-for-hundreds-of-websites/ which gives the USG top marks for effort. -- --------------------------------------------------------------- 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 mail at danrl.de Tue Oct 2 21:25:08 2012 From: mail at danrl.de (Dan Luedtke) Date: Tue, 02 Oct 2012 23:25:08 +0200 Subject: RFC becomes Visio In-Reply-To: <5065ED0E.90701@foobar.org> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> Message-ID: <1349213108.17668.1.camel@tunafish> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: > Here's a visio diagram you can send them: > > http://www.foobar.org/~nick/bgp-network-diagram.vsd Is there a .png version of it somewhere? The whole thread made my day, I'm eager to see this diagram as well. I don't have this MS Visio thingy you all use to set up your Avian Carrier BGP sessions... Regards Dan -- Dan Luedtke http://www.danrl.de From m.hallgren at free.fr Tue Oct 2 21:43:14 2012 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 02 Oct 2012 23:43:14 +0200 Subject: RFC becomes Visio In-Reply-To: <1349213108.17668.1.camel@tunafish> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> Message-ID: <1349214194.2920.1968.camel@home> Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : > On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: > > Here's a visio diagram you can send them: > > > > http://www.foobar.org/~nick/bgp-network-diagram.vsd > > Is there a .png version of it somewhere? > The whole thread made my day, I'm eager to see this diagram as well. > I don't have this MS Visio thingy you all use to set up your Avian > Carrier BGP sessions... Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or PSTRicks). The output is by far more beautiful, and maintaining the document much more slim. Cheers, mh > > Regards > > Dan > From dwhite at olp.net Tue Oct 2 22:00:12 2012 From: dwhite at olp.net (Dan White) Date: Tue, 2 Oct 2012 17:00:12 -0500 Subject: RFC becomes Visio In-Reply-To: <1349214194.2920.1968.camel@home> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> Message-ID: <20121002220011.GA6008@dan.olp.net> On 10/02/12?23:43?+0200, Michael Hallgren wrote: >Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : >> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: >> > Here's a visio diagram you can send them: >> > >> > http://www.foobar.org/~nick/bgp-network-diagram.vsd >> >> Is there a .png version of it somewhere? >> The whole thread made my day, I'm eager to see this diagram as well. >> I don't have this MS Visio thingy you all use to set up your Avian >> Carrier BGP sessions... > >Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or >PSTRicks). The output is by far more beautiful, and maintaining the >document much more slim. I'd love to use something like metapost, but have yet to find any network diagram oriented libraries. Do you have any examples that you could recommend? -- Dan White From wmaton at ottix.net Tue Oct 2 22:03:06 2012 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Tue, 2 Oct 2012 18:03:06 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <1349214194.2920.1968.camel@home> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> Message-ID: On Tue, 2 Oct 2012, Michael Hallgren wrote: > Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : >> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: >>> Here's a visio diagram you can send them: >>> >>> http://www.foobar.org/~nick/bgp-network-diagram.vsd >> >> Is there a .png version of it somewhere? >> The whole thread made my day, I'm eager to see this diagram as well. >> I don't have this MS Visio thingy you all use to set up your Avian >> Carrier BGP sessions... > > Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or > PSTRicks). The output is by far more beautiful, and maintaining the > document much more slim. I still miss doing this stuff using gpic/groff. ;-) wfms From MGauvin at dryden.ca Tue Oct 2 22:56:21 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 2 Oct 2012 17:56:21 -0500 Subject: RFC becomes Visio In-Reply-To: References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> Message-ID: Just be happy they didn't ask for power point Sent from my iPhone On 2012-10-02, at 5:03 PM, "William F. Maton Sotomayor" wrote: > On Tue, 2 Oct 2012, Michael Hallgren wrote: > >> Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : >>> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: >>>> Here's a visio diagram you can send them: >>>> >>>> http://www.foobar.org/~nick/bgp-network-diagram.vsd >>> >>> Is there a .png version of it somewhere? >>> The whole thread made my day, I'm eager to see this diagram as well. >>> I don't have this MS Visio thingy you all use to set up your Avian >>> Carrier BGP sessions... >> >> Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or >> PSTRicks). The output is by far more beautiful, and maintaining the >> document much more slim. > > I still miss doing this stuff using gpic/groff. ;-) > > wfms From ml at kenweb.org Wed Oct 3 04:43:09 2012 From: ml at kenweb.org (ML) Date: Wed, 03 Oct 2012 00:43:09 -0400 Subject: Internet routing table "completeness" monitoring? Message-ID: <506BC25D.8050603@kenweb.org> Has anyone put in place a method to identify if one their BGP peers suddenly withdraws X% of their prefixes? e.g I should expect ~420k prefixes in a "complete"[1] routing table from a transit peer today. If suddenly I'm only getting 390k prefixes I'd guess a major network was depeered or similiar. If so how are people doing this? SNMP MIB, screen scrape? [1] Varying levels of completeless apply. From ispbuilder at gmail.com Wed Oct 3 06:19:42 2012 From: ispbuilder at gmail.com (Mike) Date: Wed, 03 Oct 2012 03:19:42 -0300 Subject: Telus / AS852 Contact? Message-ID: <506BD8FE.6050107@gmail.com> Is anyone from Telus out there and willing to answer a few questions around policy / privacy? I'm hitting a roadblock trying to find out what hoops I need to jump through to get the information I need. If a super awesome Telus person can point me at the hoops, I'll start jumping. Please contact me off-list. thanks -- Looking for (employment|contract) work in the Internet industry, preferrably working remotely. Building / Supporting the net since 2400 baud was the hot thing. Ask for a resume! ispbuilder at gmail.com From saku at ytti.fi Wed Oct 3 06:52:25 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 3 Oct 2012 09:52:25 +0300 Subject: Internet routing table "completeness" monitoring? In-Reply-To: <506BC25D.8050603@kenweb.org> References: <506BC25D.8050603@kenweb.org> Message-ID: <20121003065225.GA18945@pob.ytti.fi> On (2012-10-03 00:43 -0400), ML wrote: > Has anyone put in place a method to identify if one their BGP peers > suddenly withdraws X% of their prefixes? I've had monitoring for this for many years, over SNMP. Right now my limits are a) prefix count went or came from 0 or b) relative difference is minimum 1.5x and absolute difference is minimum of 1000 Output what I get as emails: rtr1: AS702 2001:600:202::15 ge-1-0-4.BR2.LND18.ALTER.NET 0 => 34 rtr2: AS2119 148.122.8.213 ti3001b300-ge3-1-0.ti.telenor.net 688 => 0 (1/3) rtr2: AS2119 2001:4600:10::4d ti3001b300-ge3-1-0.ti.telenor.net 13 => 0 (2/3) rtr3: AS3491 80.81.192.50 br02.frf02.pccwbtn.net 37548 => 4710 And there are about 10-20 emails per day, even when looking only rather 'coarse' changes. But to be honest, I almost never peek at the folder where I get these, I'm probably moving the output on IRC channel, as I've found it superior way to keep track of alarms compared to emails for my workflow. -- ++ytti From mailing-lists at brianraaen.com Wed Oct 3 11:24:38 2012 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 3 Oct 2012 07:24:38 -0400 Subject: RFC becomes Visio In-Reply-To: <1349214194.2920.1968.camel@home> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> Message-ID: The newest version of libreoffice draw can open Visio diagrams. --- Brian Raaen Zcorum On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren wrote: > Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : >> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: >> > Here's a visio diagram you can send them: >> > >> > http://www.foobar.org/~nick/bgp-network-diagram.vsd >> >> Is there a .png version of it somewhere? >> The whole thread made my day, I'm eager to see this diagram as well. >> I don't have this MS Visio thingy you all use to set up your Avian >> Carrier BGP sessions... > > Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or > PSTRicks). The output is by far more beautiful, and maintaining the > document much more slim. > > Cheers, > mh > >> >> Regards >> >> Dan >> > > > From rodrick.brown at gmail.com Wed Oct 3 11:31:45 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Wed, 3 Oct 2012 07:31:45 -0400 Subject: RFC becomes Visio In-Reply-To: References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> Message-ID: <-9034288843230664722@unknownmsgid> On Oct 3, 2012, at 7:26 AM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: The newest version of libreoffice draw can open Visio diagrams. Also Microsoft does provide a free Visio plugin/viewer for Internet Explorer. http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=21701 --- Brian Raaen Zcorum On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren wrote: Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: Here's a visio diagram you can send them: http://www.foobar.org/~nick/bgp-network-diagram.vsd Is there a .png version of it somewhere? The whole thread made my day, I'm eager to see this diagram as well. I don't have this MS Visio thingy you all use to set up your Avian Carrier BGP sessions... Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or PSTRicks). The output is by far more beautiful, and maintaining the document much more slim. Cheers, mh Regards Dan From m.hallgren at free.fr Wed Oct 3 12:08:35 2012 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 03 Oct 2012 14:08:35 +0200 Subject: RFC becomes Visio In-Reply-To: <-9034288843230664722@unknownmsgid> References: <5065E7AE.7080504@ttec.com> <5065ED0E.90701@foobar.org> <1349213108.17668.1.camel@tunafish> <1349214194.2920.1968.camel@home> <-9034288843230664722@unknownmsgid> Message-ID: <1349266115.2920.2834.camel@home> Le mercredi 03 octobre 2012 ? 07:31 -0400, Rodrick Brown a ?crit : > On Oct 3, 2012, at 7:26 AM, Brian Christopher Raaen > wrote: > > > > The newest version of libreoffice draw can open Visio diagrams. > > > > > > > Also Microsoft does provide a free Visio plugin/viewer for Internet > Explorer. > > > http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=21701 > Can you also edit/write using these? mh > > --- > > Brian Raaen > > Zcorum > > > > On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren > > wrote: > > > Le mardi 02 octobre 2012 ? 23:25 +0200, Dan Luedtke a ?crit : > > > > On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote: > > > > > Here's a visio diagram you can send them: > > > > > > > > > > http://www.foobar.org/~nick/bgp-network-diagram.vsd > > > > > > > > Is there a .png version of it somewhere? > > > > The whole thread made my day, I'm eager to see this diagram as > > > > well. > > > > I don't have this MS Visio thingy you all use to set up your > > > > Avian > > > > Carrier BGP sessions... > > > > > > Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ > > > (or > > > PSTRicks). The output is by far more beautiful, and maintaining > > > the > > > document much more slim. > > > > > > Cheers, > > > mh > > > > > > > > > > > Regards > > > > > > > > Dan > > > > > > > > > > > > > > > > > From jra at baylink.com Wed Oct 3 13:47:18 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Oct 2012 09:47:18 -0400 (EDT) Subject: Internet routing table "completeness" monitoring? In-Reply-To: <506BC25D.8050603@kenweb.org> Message-ID: <27515462.27923.1349272038408.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "ML" > Has anyone put in place a method to identify if one their BGP peers > suddenly withdraws X% of their prefixes? > > e.g I should expect ~420k prefixes in a "complete"[1] routing table from > a transit peer today. If suddenly I'm only getting 390k prefixes I'd > guess a major network was depeered or similiar. > > If so how are people doing this? SNMP MIB, screen scrape? Well, if I had to do it, I think I'd just point munin at the router, yes, using SNMP, and put the prefix count graph up on the Big Wall, as a filled curve. That thing jumps around, someone will likely notice. This assumes a staffed NOC, of course, but it still gives you something to look at historically if you note a problem in an unstaffed situation as well. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jjackson at aninetworks.net Wed Oct 3 13:50:50 2012 From: jjackson at aninetworks.net (Joseph Jackson) Date: Wed, 3 Oct 2012 06:50:50 -0700 Subject: Internet routing table "completeness" monitoring? In-Reply-To: <506BC25D.8050603@kenweb.org> References: <506BC25D.8050603@kenweb.org> Message-ID: <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> I have cacti graph the amount of prefixes announced and withdrawn from a BGP peer on each BGP router. -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Tuesday, October 02, 2012 11:43 PM To: North American Networking and Offtopic Gripes List Subject: Internet routing table "completeness" monitoring? Has anyone put in place a method to identify if one their BGP peers suddenly withdraws X% of their prefixes? e.g I should expect ~420k prefixes in a "complete"[1] routing table from a transit peer today. If suddenly I'm only getting 390k prefixes I'd guess a major network was depeered or similiar. If so how are people doing this? SNMP MIB, screen scrape? [1] Varying levels of completeless apply. From drew.weaver at thenap.com Wed Oct 3 13:54:58 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 3 Oct 2012 09:54:58 -0400 Subject: So what's the deal with 10Gbase-T In-Reply-To: <201210012127.q91LRtS5016977@xs8.xs4all.nl> References: <201210012127.q91LRtS5016977@xs8.xs4all.nl> Message-ID: It was really unfortunate of Intel to release Romley with 10G copper only support at launch, I hear though that soon there will be motherboards with the SFP+ ports integrated. -----Original Message----- From: Miquel van Smoorenburg [mailto:mikevs at xs4all.net] Sent: Monday, October 01, 2012 5:28 PM To: andreas at livejournalinc.com Cc: nanog at nanog.org Subject: Re: So what's the deal with 10Gbase-T In article , Andreas Echavez wrote: >Does anyone here have experience running copper 10Gbase-T networks? It >seems like the standard just died out. Well, our new supermicro servers come with 10Gbase-T standard on the motherboard. >For us it would make a lot of sense >for our applications -- even if throughput and latency aren't as great. >If anyone out there knows of any *copper* 10 gig-t switches (48 port?) Arista, http://www.aristanetworks.com/ Mike. From eric-list at truenet.com Wed Oct 3 13:55:56 2012 From: eric-list at truenet.com (Eric Tykwinski) Date: Wed, 3 Oct 2012 09:55:56 -0400 Subject: Internet routing table "completeness" monitoring? In-Reply-To: <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> Message-ID: <028101cda16e$d26f5ac0$774e1040$@truenet.com> I agree, and just use the Threshold plugin so when it drops below or goes above a certain # to notify you. http://docs.cacti.net/plugin:thold -----Original Message----- From: Joseph Jackson [mailto:jjackson at aninetworks.net] Sent: Wednesday, October 03, 2012 9:51 AM To: ml at kenweb.org; North American Networking and Offtopic Gripes List Subject: RE: Internet routing table "completeness" monitoring? I have cacti graph the amount of prefixes announced and withdrawn from a BGP peer on each BGP router. From jjackson at aninetworks.net Wed Oct 3 14:01:15 2012 From: jjackson at aninetworks.net (Joseph Jackson) Date: Wed, 3 Oct 2012 07:01:15 -0700 Subject: Internet routing table "completeness" monitoring? In-Reply-To: References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> Message-ID: <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2F@EXMBX10.exchhosting.com> Not sure I don't have any non-cisco BGP routers. Sorry! -----Original Message----- From: Neil Robst [mailto:neil.robst at kit-digital.com] Sent: Wednesday, October 03, 2012 8:54 AM To: Joseph Jackson; ml at kenweb.org; North American Networking and Offtopic Gripes List Subject: RE: Internet routing table "completeness" monitoring? This is still only possible on Cisco routers, isn't it - Foundry/Brocade gear doesn't currently include an SNMP OID for this info, does it? -----Original Message----- From: Joseph Jackson [mailto:jjackson at aninetworks.net] Sent: 03 October 2012 14:51 To: ml at kenweb.org; North American Networking and Offtopic Gripes List Subject: RE: Internet routing table "completeness" monitoring? I have cacti graph the amount of prefixes announced and withdrawn from a BGP peer on each BGP router. -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Tuesday, October 02, 2012 11:43 PM To: North American Networking and Offtopic Gripes List Subject: Internet routing table "completeness" monitoring? Has anyone put in place a method to identify if one their BGP peers suddenly withdraws X% of their prefixes? e.g I should expect ~420k prefixes in a "complete"[1] routing table from a transit peer today. If suddenly I'm only getting 390k prefixes I'd guess a major network was depeered or similiar. If so how are people doing this? SNMP MIB, screen scrape? [1] Varying levels of completeless apply. From wmaton at ottix.net Wed Oct 3 14:16:48 2012 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 3 Oct 2012 10:16:48 -0400 (EDT) Subject: Internet routing table "completeness" monitoring? In-Reply-To: <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> Message-ID: On Wed, 3 Oct 2012, Joseph Jackson wrote: > I have cacti graph the amount of prefixes announced and withdrawn from a BGP peer on each BGP router. +1 Note that not all router OSs support fetching data like that via SNMP. We use a custom built thing internally that does this two, which we then tack on an alert threshold for. So if a downstream peer sends us less than that, we get an alert. Handy for those times when they call and ask us what we did to their network. :-) Prior to that, we had a script which whould login, munge the 'show ip bgp summary' table output, figure out the deltas and graph or report as needed on a particularly troublesome peer. > > > > -----Original Message----- > From: ML [mailto:ml at kenweb.org] > Sent: Tuesday, October 02, 2012 11:43 PM > To: North American Networking and Offtopic Gripes List > Subject: Internet routing table "completeness" monitoring? > > Has anyone put in place a method to identify if one their BGP peers suddenly withdraws X% of their prefixes? > > e.g I should expect ~420k prefixes in a "complete"[1] routing table from a transit peer today. If suddenly I'm only getting 390k prefixes I'd guess a major network was depeered or similiar. > > If so how are people doing this? SNMP MIB, screen scrape? > > > > [1] Varying levels of completeless apply. > > > wfms From nanog at jima.tk Wed Oct 3 14:39:15 2012 From: nanog at jima.tk (Jima) Date: Wed, 3 Oct 2012 08:39:15 -0600 (MDT) Subject: So what's the deal with 10Gbase-T In-Reply-To: References: <201210012127.q91LRtS5016977@xs8.xs4all.nl> Message-ID: <40813.2001:49f0:a057:0:691d:8aea:9fd1:4e63.1349275155.squirrel@laughton.us> Odd wording on the timing; I'm aware of at least one manufactured 1U system with onboard SFP+ that's been available since Q1-Q2 of this year. (I don't work for the manufacturer, just for a fairly happy customer.) Jima On Wed, Oct 3, 2012, at 7:54am, Drew Weaver wrote: > It was really unfortunate of Intel to release Romley with 10G copper only > support at launch, I hear though that soon there will be motherboards with > the SFP+ ports integrated. > > -----Original Message----- > From: Miquel van Smoorenburg [mailto:mikevs at xs4all.net] > Sent: Monday, October 01, 2012 5:28 PM > To: andreas at livejournalinc.com > Cc: nanog at nanog.org > Subject: Re: So what's the deal with 10Gbase-T > > In article > , > Andreas Echavez wrote: >>Does anyone here have experience running copper 10Gbase-T networks? It >>seems like the standard just died out. > > Well, our new supermicro servers come with 10Gbase-T standard on the > motherboard. > >>For us it would make a lot of sense >>for our applications -- even if throughput and latency aren't as great. >>If anyone out there knows of any *copper* 10 gig-t switches (48 port?) > > Arista, http://www.aristanetworks.com/ > > Mike. > > > From JTyler at fiberutilities.com Wed Oct 3 14:45:13 2012 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Wed, 3 Oct 2012 14:45:13 +0000 Subject: [j-nsp] Krt queue issues In-Reply-To: References: <20121001121539.GA10356@pob.ytti.fi> Message-ID: Look into Static route retain. Should keep the route in the forwarding table. >From Jniper site <<< Route Retention By default, static routes are not retained in the forwarding table when the routing process shuts down. When the routing process starts up again, any routes configured as static routes must be added to the forwarding table again. To avoid this latency, routes can be flagged as retain, so that they are kept in the forwarding table even after the routing process shuts down. Retention ensures that the routes are always in the forwarding table, even immediately after a system reboot. >>> Thanks, Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Benny Amorsen Sent: Wednesday, October 03, 2012 8:32 AM To: Jared Mauch Cc: Saku Ytti; juniper-nsp at puck.nether.net Subject: Re: [j-nsp] Krt queue issues Jared Mauch writes: > As far as the fallback 'default' route, if you are purchasing transit > from someone, you could consider a last-resort default pointed at > them. You can exclude routes like 10/8 etc by routing these to discard > + install on your devices. That only helps if the default gets installed first, though. If the default has to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not really gained anything... I suppose it is likely that a static default would be installed before the BGP sessions even come up. /Benny _______________________________________________ juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp From morrowc.lists at gmail.com Wed Oct 3 15:02:11 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Oct 2012 11:02:11 -0400 Subject: Internet routing table "completeness" monitoring? In-Reply-To: <028101cda16e$d26f5ac0$774e1040$@truenet.com> References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> <028101cda16e$d26f5ac0$774e1040$@truenet.com> Message-ID: On Wed, Oct 3, 2012 at 9:55 AM, Eric Tykwinski wrote: > I agree, and just use the Threshold plugin so when it drops below or goes > above a certain # to notify you. > http://docs.cacti.net/plugin:thold is a threshold helpful here? (well, it's helpful to a point at least) what if your neighbour starts deaggragating (or sending you their internal deaggragates) in place of 50k real routes? no alarm, no 'change' from a numbers perspective, but certainly a traffic shift and reach-ability change :( Isn't a speed-of-change threshold also interesting here? From akg1330 at gmail.com Wed Oct 3 15:34:48 2012 From: akg1330 at gmail.com (Andrew Gallo) Date: Wed, 03 Oct 2012 11:34:48 -0400 Subject: Internet routing table "completeness" monitoring? In-Reply-To: References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> Message-ID: <506C5B18.4070106@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/3/2012 10:16 AM, William F. Maton Sotomayor wrote: > On Wed, 3 Oct 2012, Joseph Jackson wrote: > >> I have cacti graph the amount of prefixes announced and withdrawn from a BGP peer on each BGP router. > > +1 > > Note that not all router OSs support fetching data like that via SNMP. > > We use a custom built thing internally that does this two, which we then tack on an alert threshold for. So if a downstream peer sends us less than that, we get an alert. Handy for those times when they call and ask us what we did to their network. :-) > > Prior to that, we had a script which whould login, munge the 'show ip bgp summary' table output, figure out the deltas and graph or report as needed on a particularly troublesome peer. > >> >> >> >> -----Original Message----- >> From: ML [mailto:ml at kenweb.org] >> Sent: Tuesday, October 02, 2012 11:43 PM >> To: North American Networking and Offtopic Gripes List >> Subject: Internet routing table "completeness" monitoring? >> >> Has anyone put in place a method to identify if one their BGP peers suddenly withdraws X% of their prefixes? >> >> e.g I should expect ~420k prefixes in a "complete"[1] routing table from a transit peer today. If suddenly I'm only getting 390k prefixes I'd guess a major network was depeered or similiar. >> >> If so how are people doing this? SNMP MIB, screen scrape? >> >> >> >> [1] Varying levels of completeless apply. >> >> >> > > wfms > > So, there is something called the BGP Monitoring Protocol (BMP): http://tools.ietf.org/html/draft-ietf-grow-bmp-06 http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTM2NiZuYW5vZzQ1&nm=nanog45 Looks like it is supported in JunOS. Has anyone used it? If so, what monitoring software are you using? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQbFsYAAoJEBxhAh+LWUKi/WwIAKxVmcCfI6xng0lAL5UxHSGK v+fp5Q1d40hCu1aWWeeV/eYvyOEZSwkY/jSK0EaVrdmv0y4GQttQqSfGk+1RQOK/ jZAD/r0Fd9K9vMLJ5Te+bkjYuOp23G2bDn8QWuls4HBc1nHxkPc6arzUTgTzEFAZ +Ljk3MQSHiZ+nb6fkX+Yb7e3UJZjpkuWaNeqGcKz9FR9PJT5UZI8Yf2iwMHtVl/l R9XfAIG/xDd64oKEDbt8JmtQkqS64ZnCFe+B/yEuTKC6Pl0DUm4orH7322oxjxOW yDloqmhO5pCmVETFHwn0ocTpDKqG2zE4zA4bHL+w+xePSS61DpUf51V3eg8JgZo= =Ofld -----END PGP SIGNATURE----- From chris at ctcampbell.com Wed Oct 3 16:13:54 2012 From: chris at ctcampbell.com (Chris Campbell) Date: Wed, 3 Oct 2012 17:13:54 +0100 Subject: IPv4 address length technical design Message-ID: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? Cheers. From sadiq at asininetech.com Wed Oct 3 16:19:29 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Wed, 3 Oct 2012 12:19:29 -0400 Subject: IPv4 address length technical design In-Reply-To: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Message-ID: On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell wrote: > Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? > > Cheers. I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791 -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From kbroder at accretive-networks.net Wed Oct 3 16:33:25 2012 From: kbroder at accretive-networks.net (Kevin Broderick) Date: Wed, 03 Oct 2012 09:33:25 -0700 Subject: IPv4 address length technical design In-Reply-To: References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Message-ID: <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint Cerf expressed some regret over going with 32 bits. Chuckle worthy and at the time, and a fond memory - K Sadiq Saif wrote: >On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell >wrote: >> Is anyone aware of any historical documentation relating to the >choice of 32 bits for an IPv4 address? >> >> Cheers. > >I believe the relevant RFC is RFC 791 - >https://tools.ietf.org/html/rfc791 > >-- >Sadiq S >O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From seth.mos at dds.nl Wed Oct 3 16:52:57 2012 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 03 Oct 2012 18:52:57 +0200 Subject: IPv4 address length technical design In-Reply-To: <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> Message-ID: <506C6D69.5080506@dds.nl> Op 3-10-2012 18:33, Kevin Broderick schreef: > I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint Cerf expressed some regret over going with 32 bits. Chuckle worthy and at the time, and a fond memory > - K "Pick a number between this and that." It's the 80's and you can still count the computers in the world. :) It is/was a "experiment" and you have the choice between a really large and a larger number. Humans are not too good in comparing really large numbers. If it was ever decided to use a smaller value, for the size of the experiment it might have went quite different. The "safe" (larger) choice ended up bringing more pain. As a time honored ritual, the temporary solution becomes the production solution. Oops... And that was not quite what Mr Cerf meant to do. Regards, Seth From rs at seastrom.com Wed Oct 3 17:17:11 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 03 Oct 2012 13:17:11 -0400 Subject: IPv4 address length technical design In-Reply-To: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> (Chris Campbell's message of "Wed, 3 Oct 2012 17:13:54 +0100") References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Message-ID: <86mx031nmw.fsf@seastrom.com> Chris Campbell writes: > Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? > > Cheers. 8 bit host identifiers had proven to be too short... :) -r From streiner at cluebyfour.org Wed Oct 3 18:21:37 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 3 Oct 2012 14:21:37 -0400 (EDT) Subject: Internet routing table "completeness" monitoring? In-Reply-To: References: <506BC25D.8050603@kenweb.org> <6D497FE8AFD83E49AFADD9114C569F8F0C97E72D2B@EXMBX10.exchhosting.com> <028101cda16e$d26f5ac0$774e1040$@truenet.com> Message-ID: On Wed, 3 Oct 2012, Christopher Morrow wrote: > is a threshold helpful here? (well, it's helpful to a point at least) > what if your neighbour starts deaggragating (or sending you their > internal deaggragates) in place of 50k real routes? no alarm, no > 'change' from a numbers perspective, but certainly a traffic shift and > reach-ability change :( As long as you have some control over the number of polling intervals between the detection of a noteworthy change and sending an alarm. Otherwise, there is a real danger of your NOC having to investigate a lot of noisy alerts. If that persists for too long, the NOC will grow tired of responding to these alerts, and send them all to the bit bucket, or implement their own polling thresholds that meet their needs more effectively. If a network you have no business relationship with and several AS hops away from you goes away, how much effort do you want to expend investigating that? That probably depends on your customers. If you see a few hundred routes disappear and determine them to be for an ISP on the other side of the planet, that's one thing. If your view of something like Google or Facebook suddenly disappears, that could be another thing entirely ;) > Isn't a speed-of-change threshold also interesting here? +1 on that :) jms From alh-ietf at tndh.net Wed Oct 3 19:11:05 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 3 Oct 2012 12:11:05 -0700 Subject: IPv4 address length technical design In-Reply-To: References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Message-ID: <006b01cda19a$d650fdc0$82f2f940$@tndh.net> > Sadiq Saif [mailto:sadiq at asininetech.com] wrote: > > On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell > wrote: > > Is anyone aware of any historical documentation relating to the choice of 32 > bits for an IPv4 address? > > > > Cheers. > > I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791 Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is partially available on a series of pages starting at : http://www.networksorcery.com/enp/default1101.htm IEN 2 is likely to be of particular interest ... From izaac at setec.org Wed Oct 3 19:22:21 2012 From: izaac at setec.org (Izaac) Date: Wed, 3 Oct 2012 15:22:21 -0400 Subject: IPv4 address length technical design In-Reply-To: <506C6D69.5080506@dds.nl> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> Message-ID: <20121003T191621Z@localhost> On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote: > "Pick a number between this and that." It's the 80's and you can > still count the computers in the world. :) And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go figure. I'm pretty sure the explanation you're looking for is: It was with the word size of the most popular minis and micros at the time. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From george.herbert at gmail.com Wed Oct 3 19:27:46 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 3 Oct 2012 12:27:46 -0700 Subject: IPv4 address length technical design In-Reply-To: <006b01cda19a$d650fdc0$82f2f940$@tndh.net> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <006b01cda19a$d650fdc0$82f2f940$@tndh.net> Message-ID: On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain wrote: >> Sadiq Saif [mailto:sadiq at asininetech.com] wrote: >> >> On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell >> wrote: >> > Is anyone aware of any historical documentation relating to the choice of 32 >> bits for an IPv4 address? >> > >> > Cheers. >> >> I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791 > > Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is partially available on a series of pages starting at : http://www.networksorcery.com/enp/default1101.htm > IEN 2 is likely to be of particular interest ... It's worthwhile noting that the state of system (mini and microcomputer) art at the time of the 1977 discussions was, for example, the Intel 8085 (8-bit registers; the 16-bit 8086 was 1978) and 16-bit PDP-11s. The 32-bit VAX 11/780 postdated these (announced October 77). Yes, you can do 32 or 64 bit network addressing with smaller registers, but there are tendencies to not think that way. -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Wed Oct 3 19:31:48 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 3 Oct 2012 12:31:48 -0700 Subject: IPv4 address length technical design In-Reply-To: <20121003T191621Z@localhost> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> <20121003T191621Z@localhost> Message-ID: On Wed, Oct 3, 2012 at 12:22 PM, Izaac wrote: > On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote: >> "Pick a number between this and that." It's the 80's and you can >> still count the computers in the world. :) > > And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go > figure. I'm pretty sure the explanation you're looking for is: It was > with the word size of the most popular minis and micros at the time. The 48 bit MAC was 1980; notable that it was not primarily handled in software / CPUs (ethernet key functionality is in dedicated interface hardware, though the stack is MAC-aware obviously). CPU register bit length is less critical when you have a dedicated controller of arbitrary bittedness handling MACs. -- -george william herbert george.herbert at gmail.com From tony at swalter.com Wed Oct 3 19:44:16 2012 From: tony at swalter.com (Tony Patti) Date: Wed, 3 Oct 2012 15:44:16 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <006b01cda19a$d650fdc0$82f2f940$@tndh.net> Message-ID: <143e01cda19f$78b544f0$6a1fced0$@swalter.com> Perhaps worth noting (for the archives) that a significant part of the early ARPAnet was DECsystem-10's with 36-bit words. http://en.wikipedia.org/wiki/PDP-10 http://en.wikipedia.org/wiki/Email Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Wednesday, October 03, 2012 3:28 PM To: Tony Hain Cc: nanog at nanog.org Subject: Re: IPv4 address length technical design On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain wrote: It's worthwhile noting that the state of system (mini and microcomputer) art at the time of the 1977 discussions was, for example, the Intel 8085 (8-bit registers; the 16-bit 8086 was 1978) and 16-bit PDP-11s. The 32-bit VAX 11/780 postdated these (announced October 77). Yes, you can do 32 or 64 bit network addressing with smaller registers, but there are tendencies to not think that way. From Valdis.Kletnieks at vt.edu Wed Oct 3 19:59:12 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Oct 2012 15:59:12 -0400 Subject: IPv4 address length technical design In-Reply-To: Your message of "Wed, 03 Oct 2012 15:44:16 -0400." <143e01cda19f$78b544f0$6a1fced0$@swalter.com> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <006b01cda19a$d650fdc0$82f2f940$@tndh.net> <143e01cda19f$78b544f0$6a1fced0$@swalter.com> Message-ID: <19741.1349294352@turing-police.cc.vt.edu> On Wed, 03 Oct 2012 15:44:16 -0400, "Tony Patti" said: > > Perhaps worth noting (for the archives) that a significant part of the early > ARPAnet was DECsystem-10's with 36-bit words. And the -10s and -20s were the major reason RFCs refer to octets rather than bytes, as they had a rather slippery notion of "byte" (anywhere from 6 to 9 bits, often multiple sizes used *in the same program*). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Wed Oct 3 20:13:17 2012 From: bill at herrin.us (William Herrin) Date: Wed, 3 Oct 2012 16:13:17 -0400 Subject: IPv4 address length technical design In-Reply-To: <20121003T191621Z@localhost> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> <20121003T191621Z@localhost> Message-ID: On Wed, Oct 3, 2012 at 3:22 PM, Izaac wrote: > On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote: >> "Pick a number between this and that." It's the 80's and you can >> still count the computers in the world. :) > > And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go > figure. I'm pretty sure the explanation you're looking for is: It was > with the word size of the most popular minis and micros at the time. It wasn't. At the time. But at some point people of vision figured out that CPU word sizes would standardize on power-of-two powers of two. Really helps when you want to align data elements in memory if exactly 2 16 bit integers fit in the 32 bit word and exactly 2 32 bit integers fit in the 64 bit word. "And a half" is a phrase that makes life miserable in both software development and hardware design. IEEE figured it out later. The replacement for the MAC address is EUI-64. I still haven't figured out Bell's excuse with ATM. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dhc2 at dcrocker.net Wed Oct 3 20:17:01 2012 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 03 Oct 2012 13:17:01 -0700 Subject: IPv4 address length technical design In-Reply-To: <006b01cda19a$d650fdc0$82f2f940$@tndh.net> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <006b01cda19a$d650fdc0$82f2f940$@tndh.net> Message-ID: <506C9D3D.8090301@dcrocker.net> >>> Is anyone aware of any historical documentation relating to the >>> choice of 32 >> bits for an IPv4 address? ... > Actually that was preceded by RFC 760, which in turn was a derivative > of IEN 123. I believe the answer to the original question is ... My theory is that there is a meta-rule to make new address spaces have 4 times as many bits as the previous generation. We have three data points to establish this for the Internet, and that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jra at baylink.com Wed Oct 3 21:09:54 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Oct 2012 17:09:54 -0400 (EDT) Subject: IPv4 address length technical design In-Reply-To: <506C9D3D.8090301@dcrocker.net> Message-ID: <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave Crocker" > My theory is that there is a meta-rule to make new address spaces have > 4 times as many bits as the previous generation. > > We have three data points to establish this for the Internet, and > that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6... So the address space for IPv8 will be... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From surfer at mauigateway.com Wed Oct 3 21:19:22 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 3 Oct 2012 14:19:22 -0700 Subject: IPv4 address length technical design Message-ID: <20121003141922.B6A88909@m0005311.ppops.net> --- jra at baylink.com wrote: From: Jay Ashworth So the address space for IPv8 will be... ------------------------------------------------- Jim says: "IPv8 - 43 bits (3+8+32) There is a natural routing hierarchy with IPv8 addressing....8 regions, 256 distribution centers in each region and full 32 bit Internets from there. IPv8 addresses can fit inside the IPv6 address fields." >;-) scott From george.herbert at gmail.com Wed Oct 3 21:26:55 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 3 Oct 2012 14:26:55 -0700 Subject: IPv4 address length technical design In-Reply-To: <20121003141922.B6A88909@m0005311.ppops.net> References: <20121003141922.B6A88909@m0005311.ppops.net> Message-ID: On Wed, Oct 3, 2012 at 2:19 PM, Scott Weeks wrote: > > > --- jra at baylink.com wrote: > From: Jay Ashworth > > So the address space for IPv8 will be... > > ------------------------------------------------- > > > Jim says: > > "IPv8 - 43 bits (3+8+32) > > There is a natural routing hierarchy with IPv8 > addressing....8 regions, 256 distribution centers > in each region and full 32 bit Internets from there. > IPv8 addresses can fit inside the IPv6 address fields." > > >>;-) > scott One bit of network address, used to designate whether it is a broadcast or single-host-recipient packet. And 511 bit MAC addresses... (L2 Uber Alles. Routers are for the Weak.) -- -george william herbert george.herbert at gmail.com From SNaslund at medline.com Wed Oct 3 21:30:53 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 3 Oct 2012 16:30:53 -0500 Subject: IPv4 address length technical design In-Reply-To: <506C6D69.5080506@dds.nl> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C996C59@MUNEXBE1.medline.com> Remember that at the time, IP was designed to be classful so having four 8 bit bytes was real convenient to look only at the bytes in the host portion of the address. Class A meant three significant bytes, Class B had two significant bytes, and Class C had three significant bytes as far as the host portion of the address. If we are looking for matches in a routing table it is much easier to search for an entire matching byte than to do it bitwise. Even though systems had varying byte lengths, 8 was still the most common because it was the easiest to map extended ASCII into. Now we could discuss whether there should have been more bytes but at the time no one had really envisioned the public deployment of this at the scales we see today. Same reason IBM and Microsoft had barriers like 640k of RAM, no one just ever thought you would need more than that. Steven Naslund -----Original Message----- From: Seth Mos [mailto:seth.mos at dds.nl] Sent: Wednesday, October 03, 2012 11:53 AM To: nanog at nanog.org Subject: Re: IPv4 address length technical design Op 3-10-2012 18:33, Kevin Broderick schreef: > I'll add that in the mid-90's, in a University Of Washington lecture > hall, Vint Cerf expressed some regret over going with 32 bits. > Chuckle worthy and at the time, and a fond memory > - K "Pick a number between this and that." It's the 80's and you can still count the computers in the world. :) It is/was a "experiment" and you have the choice between a really large and a larger number. Humans are not too good in comparing really large numbers. If it was ever decided to use a smaller value, for the size of the experiment it might have went quite different. The "safe" (larger) choice ended up bringing more pain. As a time honored ritual, the temporary solution becomes the production solution. Oops... And that was not quite what Mr Cerf meant to do. Regards, Seth From SNaslund at medline.com Wed Oct 3 21:50:03 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 3 Oct 2012 16:50:03 -0500 Subject: [j-nsp] Krt queue issues In-Reply-To: References: <20121001121539.GA10356@pob.ytti.fi> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> I think route retention might help in the event the table was cleared or routing process restarted but I don't that it will help with a boot because the table structures are being built as part of the system initialization. In reality, I would expect the static routes to get installed very early as soon as the routing process comes up. Since you will need a route to your BGP neighbor (even though it may be directly connected, it is still a route), routing has to be up BEFORE BGP establishes and by definition your static routes will have to be up before your BGP routes are ready. How well your router responds to traffic during an initial boot and during a 300,000 route update is another story. My experience with very large routers and tables is that you will have a hard time guaranteeing user traffic will pass with very much performance during an event like a full table rebuild. Luckily with the bandwidth we have these days and the CPU power on the routers, it does not take that long to pull in a full internet table and begin handling traffic. Steven Naslund -----Original Message----- From: Jensen Tyler [mailto:JTyler at fiberutilities.com] Sent: Wednesday, October 03, 2012 9:45 AM To: nanog at nanog.org Subject: RE: [j-nsp] Krt queue issues Look into Static route retain. Should keep the route in the forwarding table. >From Jniper site <<< Route Retention By default, static routes are not retained in the forwarding table when the routing process shuts down. When the routing process starts up again, any routes configured as static routes must be added to the forwarding table again. To avoid this latency, routes can be flagged as retain, so that they are kept in the forwarding table even after the routing process shuts down. Retention ensures that the routes are always in the forwarding table, even immediately after a system reboot. >>> Thanks, Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Benny Amorsen Sent: Wednesday, October 03, 2012 8:32 AM To: Jared Mauch Cc: Saku Ytti; juniper-nsp at puck.nether.net Subject: Re: [j-nsp] Krt queue issues Jared Mauch writes: > As far as the fallback 'default' route, if you are purchasing transit > from someone, you could consider a last-resort default pointed at > them. You can exclude routes like 10/8 etc by routing these to discard > + install on your devices. That only helps if the default gets installed first, though. If the default has to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not really gained anything... I suppose it is likely that a static default would be installed before the BGP sessions even come up. /Benny _______________________________________________ juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp From owen at delong.com Wed Oct 3 22:21:54 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Oct 2012 15:21:54 -0700 Subject: IPv4 address length technical design In-Reply-To: <20121003T191621Z@localhost> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> <20121003T191621Z@localhost> Message-ID: On Oct 3, 2012, at 12:22 PM, Izaac wrote: > On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote: >> "Pick a number between this and that." It's the 80's and you can >> still count the computers in the world. :) > > And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go > figure. I'm pretty sure the explanation you're looking for is: It was > with the word size of the most popular minis and micros at the time. > IEEE 802 was expected to provide unique numbers for all computers ever built. Internet was expected to provide unique numbers for all computers actively on the network. Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. Owen From dmburgess at linktechs.net Wed Oct 3 22:45:47 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 3 Oct 2012 17:45:47 -0500 Subject: Rogers.ca fiber contact Message-ID: <50710E9A7E64454C974049FC998EB655681B81@03-exchange.lti.local> Have a fiber circuit that is getting inconsistent speeds to the net L Need an IPERF test on rogers network to verify bandwidth. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace 5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA From mysidia at gmail.com Wed Oct 3 22:49:56 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 3 Oct 2012 17:49:56 -0500 Subject: IPv4 address length technical design In-Reply-To: <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: On 10/3/12, Jay Ashworth wrote: > So the address space for IPv8 will be... > In 100 years, when we start to run out of IPv6 addresses, possibly we will have learned our lesson and done two things: (1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no "Netmasks", "Prefix lengths", or other comingling of network addresses and host address spaces. And (2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP, with a convention of a specified length, instead of a hardwired specific limit that comes from using a permanently fixed-width field. Need more bits? No protocol definition change required. > Cheers, > -- jra -- -JH From Valdis.Kletnieks at vt.edu Wed Oct 3 22:59:20 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Oct 2012 18:59:20 -0400 Subject: IPv4 address length technical design In-Reply-To: Your message of "Wed, 03 Oct 2012 17:49:56 -0500." References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: <28390.1349305160@turing-police.cc.vt.edu> On Wed, 03 Oct 2012 17:49:56 -0500, Jimmy Hess said: > (1) Stopped mixing the Host identification and the Network > identification into the same bit field; instead every packet gets a > source network address, destination network address, AND an > additional tuple of Source host address, destination host > address; residing in completely separate address spaces, with no > "Netmasks", "Prefix lengths", or other comingling of network > addresses and host address spaces. Where's Noel Chiappa when you need him? > (2) The new protocol will use variable-length address for the Host > portion, such as used in the addresses of CLNP, This also was considered during the IPv6 design phase, and the router designers had a collective cow, as it makes ASIC design a whole lot more interesting. And back then, line speed was a lot lower than it is now... Not saying it can't be done - but you're basically going to have to do CLNP style handling at 400Gbits or 1Tbit. Better get those ASIC designers a *lot* of caffeine, they're gonna need it... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From drc at virtualized.org Wed Oct 3 23:05:31 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 3 Oct 2012 16:05:31 -0700 Subject: IPv4 address length technical design In-Reply-To: <28390.1349305160@turing-police.cc.vt.edu> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> Message-ID: On Oct 3, 2012, at 3:59 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 03 Oct 2012 17:49:56 -0500, Jimmy Hess said: >> (1) Stopped mixing the Host identification and the Network >> identification into the same bit field; > > Where's Noel Chiappa when you need him? Saying "I told you so" I suspect. >> (2) The new protocol will use variable-length address for the Host >> portion, such as used in the addresses of CLNP, > This also was considered during the IPv6 design phase, and the router > designers had a collective cow, as it makes ASIC design a whole lot more > interesting. Where are Tony Li, Paul Traina, and the whole TUBA orchestra when you need them? :-) Regards, -drc From james.cutler at consultant.com Wed Oct 3 23:10:04 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 3 Oct 2012 19:10:04 -0400 Subject: IPv4 address length technical design In-Reply-To: <506C9D3D.8090301@dcrocker.net> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <006b01cda19a$d650fdc0$82f2f940$@tndh.net> <506C9D3D.8090301@dcrocker.net> Message-ID: <5A427527-A4D5-4D83-AAF0-EEFCFE13215A@consultant.com> On Oct 3, 2012, at 4:17 PM, Dave Crocker wrote: >>>> Is anyone aware of any historical documentation relating to the >>>> choice of 32 >>> bits for an IPv4 address? > ... >> Actually that was preceded by RFC 760, which in turn was a derivative >> of IEN 123. I believe the answer to the original question is > ... > > > My theory is that there is a meta-rule to make new address spaces have 4 > times as many bits as the previous generation. > > We have three data points to establish this for the Internet, and that's > the minimum needed to run a correlation: Arpanet, IPv4, IPv6... > > d/ Didn't work for DecNet Phase III, Decnet Phase IV, Decnet Phase V (8, 16, 128). From james.cutler at consultant.com Wed Oct 3 23:12:58 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 3 Oct 2012 19:12:58 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: On Oct 3, 2012, at 6:49 PM, Jimmy Hess wrote: > On 10/3/12, Jay Ashworth wrote: >> So the address space for IPv8 will be... >> > > In 100 years, when we start to run out of IPv6 addresses, possibly we > will have learned our lesson and done two things: > > (1) Stopped mixing the Host identification and the Network > identification into the same bit field; instead every packet gets a > source network address, destination network address, AND an > additional tuple of Source host address, destination host > address; residing in completely separate address spaces, with no > "Netmasks", "Prefix lengths", or other comingling of network > addresses and host address spaces. > > And > (2) The new protocol will use variable-length address for the Host > portion, such as used in the addresses of CLNP, with a convention of > a specified length, instead of a hardwired specific limit that comes > from using a permanently fixed-width field. > > Need more bits? No protocol definition change required. > > >> Cheers, >> -- jra > -- > -JH > I suggest that the DNS name space should be considered to be an "hierarchical host address space" thus satisfying (1) and making (2) moot. From owen at delong.com Wed Oct 3 23:15:04 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Oct 2012 16:15:04 -0700 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> On Oct 3, 2012, at 3:49 PM, Jimmy Hess wrote: > On 10/3/12, Jay Ashworth wrote: >> So the address space for IPv8 will be... >> > > In 100 years, when we start to run out of IPv6 addresses, possibly we > will have learned our lesson and done two things: > > (1) Stopped mixing the Host identification and the Network > identification into the same bit field; instead every packet gets a > source network address, destination network address, AND an > additional tuple of Source host address, destination host > address; residing in completely separate address spaces, with no > "Netmasks", "Prefix lengths", or other comingling of network > addresses and host address spaces. > Agreed, mostly. Prefix lengths can still be useful for route summarization and it would be useful to have separate segments of the network address, such as Autonomous System Number, Intra-AS Organizational Identifier, and Intra-Organizational Network, for example. It might be useful to use prefix lengths in those cases to allow for variability in the boundary between these identifiers. > And > (2) The new protocol will use variable-length address for the Host > portion, such as used in the addresses of CLNP, with a convention of > a specified length, instead of a hardwired specific limit that comes > from using a permanently fixed-width field. > On this, I disagree? Once host identifiers are no longer dependent on or related to topology, there's no reason a reasonable fixed-length cannot suffice. > Need more bits? No protocol definition change required. > Nope, just new ASICS everywhere and no clear way to identify where they are or are not deployed and? Owen From george.herbert at gmail.com Wed Oct 3 23:36:41 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 3 Oct 2012 16:36:41 -0700 Subject: IPv4 address length technical design In-Reply-To: <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> Message-ID: On Wed, Oct 3, 2012 at 4:15 PM, Owen DeLong wrote: > > On Oct 3, 2012, at 3:49 PM, Jimmy Hess wrote: > >> On 10/3/12, Jay Ashworth wrote: >>> So the address space for IPv8 will be... >>> >> >> In 100 years, when we start to run out of IPv6 addresses, possibly we >> will have learned our lesson and done two things: >> >> (1) Stopped mixing the Host identification and the Network >> identification into the same bit field; instead every packet gets a >> source network address, destination network address, AND an >> additional tuple of Source host address, destination host >> address; residing in completely separate address spaces, with no >> "Netmasks", "Prefix lengths", or other comingling of network >> addresses and host address spaces. >> > > Agreed, mostly. > > Prefix lengths can still be useful for route summarization and it would > be useful to have separate segments of the network address, such as > Autonomous System Number, Intra-AS Organizational Identifier, and > Intra-Organizational Network, for example. It might be useful to use > prefix lengths in those cases to allow for variability in the boundary > between these identifiers. > >> And >> (2) The new protocol will use variable-length address for the Host >> portion, such as used in the addresses of CLNP, with a convention of >> a specified length, instead of a hardwired specific limit that comes >> from using a permanently fixed-width field. >> > > On this, I disagree? Once host identifiers are no longer dependent on or > related to topology, there's no reason a reasonable fixed-length cannot > suffice. > >> Need more bits? No protocol definition change required. >> > > Nope, just new ASICS everywhere and no clear way to identify where they > are or are not deployed and? A regrettably serious response: There are some fundamental questions about areas of computer usage, engineering, and science that will affect what "the next protocol" should look like. Despite a couple of decades of frenetic work to mobility-ize our protocols, we mostly didn't with IPv6; that may be the norm rather than the design exception by $NEXTPROTOCOL. Quantum computers may, or may not, be relevant to anything (including possibly routing or switching) by $NEXTPROTOCOL days. Supermassive parallelism may be relevant to routing or switching. Moore's Law may peter out at some point with Silicon hitting atom-count limits, or could continue somewhat further with nanowires and graphene and the like, or something else completely could come about. Extremely low cost concerns may collapse the number of physical devices in a computer / computing device, as we have see many cycles of various system controllers or video controllers migrating into CPUs or back out again as performance or chip cost concerns / fab technology pushed the optimization point one way or the other. This could affect switch and router cost optimization as well. We can (probably safely) say that within the next decade there is no sign of a technical or business driver for $NEXTPROTOCOL bubbling over our feet; by the time that it becomes necessary or relevant, all the ASICS we have out there now will be obsolete. Whether they're just faster smaller ASICS or some form of interface we cannot currently accurately predict, I have no idea, but I would rather not limit our conceptualization of 20-100 year timeframe solutions to "Today, but faster". If we go back to 1992, it is almost completely an accident that winning technologies in many areas today are still recognizable to the computer people of that era. -- -george william herbert george.herbert at gmail.com From bzs at world.std.com Wed Oct 3 23:36:34 2012 From: bzs at world.std.com (Barry Shein) Date: Wed, 3 Oct 2012 19:36:34 -0400 Subject: IPv4 address length technical design In-Reply-To: <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: <20588.52226.462858.445828@world.std.com> On October 3, 2012 at 17:09 jra at baylink.com (Jay Ashworth) wrote: > > So the address space for IPv8 will be... > Variable. -b From eugen at leitl.org Thu Oct 4 06:47:45 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 4 Oct 2012 08:47:45 +0200 Subject: IPv4 address length technical design In-Reply-To: <28390.1349305160@turing-police.cc.vt.edu> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> Message-ID: <20121004064745.GB9750@leitl.org> On Wed, Oct 03, 2012 at 06:59:20PM -0400, Valdis.Kletnieks at vt.edu wrote: > Where's Noel Chiappa when you need him? > > > (2) The new protocol will use variable-length address for the Host > > portion, such as used in the addresses of CLNP, > > This also was considered during the IPv6 design phase, and the router > designers had a collective cow, as it makes ASIC design a whole lot more > interesting. And back then, line speed was a lot lower than it is now... > > Not saying it can't be done - but you're basically going to have to do CLNP > style handling at 400Gbits or 1Tbit. Better get those ASIC designers a *lot* > of caffeine, they're gonna need it... Except that these will be pure photonic networks, and apart from optical delay lines for your packet buffer you'd better be able to make a routing (switching) decision while few bits of the header have streamed by your photonic router circuit. There is no time for any table look-ups, obviously. And optical gates are *really* expensive, so better use few of them. And don't add too many gate delays, too. Above describes your setting for the next protocol. There is not a lot of leeway in design space, I'm afraid. From bygg at cafax.se Thu Oct 4 09:57:34 2012 From: bygg at cafax.se (Johnny Eriksson) Date: Thu, 4 Oct 2012 9:57:34 WET DST Subject: IPv4 address length technical design In-Reply-To: Your message of Wed, 03 Oct 2012 15:59:12 -0400 Message-ID: Valdis.Kletnieks at vt.edu wrote: > And the -10s and -20s were the major reason RFCs refer to octets > rather than bytes, as they had a rather slippery notion of "byte" > (anywhere from 6 to 9 bits, often multiple sizes used *in the > same program*). Not quite correct. Anywhere from 1 to 36 bits, and not spanning a 36-bit word boundary. Essentialy what is now known as a bit field. --Johnny From mohta at necom830.hpcl.titech.ac.jp Thu Oct 4 08:10:00 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 04 Oct 2012 17:10:00 +0900 Subject: IPv4 address length technical design In-Reply-To: <20121004064745.GB9750@leitl.org> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> Message-ID: <506D4458.6070609@necom830.hpcl.titech.ac.jp> Eugen Leitl wrote: > Except that these will be pure photonic networks, and apart from optical > delay lines for your packet buffer you'd better be able to make a routing > (switching) decision Seriously speaking, that is the likely future as 1T Ethernet will be impractical. The point is to use 1Tbps packet by encoding a packet simultaneously over, for example, 100 wavelengths each encoded at 10Gbps. > while few bits of the header have streamed by your > photonic router circuit. > > There is no time for any table look-ups, obviously. At 1Tbps, 500B packet is 4ns long, which is long enough for full /24 (with limited support for /32) look up. While wavelengths containing header information are used for table look up and rewritten, rest of the wavelengths are delayed. What you can't use with fiber delay lines is hash table, which means large number (beyond CAM capacity) of Ethernet MAC addresses is unusable and IPv6 with current allocation scheme is bad. > And optical gates are *really* expensive, so better use few of > them. And don't add too many gate delays, too. That's one reason why we should use 1Tbps packets. A gate should switch not 10Gbps but 1Tbps or faster data. Another reason is that 1Tbps packet needs 100 times shorter delay lines to buffer than 10Gbps ones. > Above describes your setting for the next protocol. There is not > a lot of leeway in design space, I'm afraid. Just keep using IPv4. Masataka Ohta PS See ftp://chacha.hpcl.titech.ac.jp/IEEE-ST.ppt presented at a summer topical of IEEE photonic society. From mch-nanog at xs4all.nl Thu Oct 4 08:31:34 2012 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Thu, 4 Oct 2012 10:31:34 +0200 Subject: IPv4 address length technical design In-Reply-To: References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> <20121003T191621Z@localhost> Message-ID: <737E51D7-DCD8-4423-BF7F-B910EAB23314@xs4all.nl> On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote: > IEEE 802 was expected to provide unique numbers for all computers ever built. > > Internet was expected to provide unique numbers for all computers actively on the network. > > Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. Which brings the question, are we expected to ever run out of the 48 bits for mac-addresses? Of course there are exceptions, but in most cases you can probably start recycling them after a certain period. And that period could even become shorter over time, I mean what are the chances you find a iPhone 1 in your network these days? Marco From eugen at leitl.org Thu Oct 4 08:49:16 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 4 Oct 2012 10:49:16 +0200 Subject: [tt] IPv4 address length technical design In-Reply-To: <506D4458.6070609@necom830.hpcl.titech.ac.jp> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <506D4458.6070609@necom830.hpcl.titech.ac.jp> Message-ID: <20121004084916.GI9750@leitl.org> On Thu, Oct 04, 2012 at 05:10:00PM +0900, Masataka Ohta wrote: > > Above describes your setting for the next protocol. There is not > > a lot of leeway in design space, I'm afraid. > > Just keep using IPv4. > > Masataka Ohta > PS > > See ftp://chacha.hpcl.titech.ac.jp/IEEE-ST.ppt presented > at a summer topical of IEEE photonic society. Thanks for the Powerpoint, I've already seen it or an earlier version of it. My (minor) beef with it is that while you offload most of heavy lifting to photonics you still use electronics and lookup. It is however reasonably easy to do everything at effectively L2 with a photonic crossbar if you encode geography in the headers (you have a direct proximity metric on your link slots). (You can actually prototype this with Ethernet MACs, as 2^48 in square meters happens to be half the surface area of the Earth http://www.wolframalpha.com/input/?i=2^48+m^2 So MAC collisions are not very probable, if distributed optimally ;) If you do it in optics the protocol is completely different from IPv4/IPv6, so you would encapsulate and use it as a transport layer for legacy (ha!) protocols. P.S. Sorry for shit-stirring (and it ain't even Friday yet). I'll be good now. From mohta at necom830.hpcl.titech.ac.jp Thu Oct 4 09:58:13 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 04 Oct 2012 18:58:13 +0900 Subject: [tt] IPv4 address length technical design In-Reply-To: <20121004084916.GI9750@leitl.org> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <506D4458.6070609@necom830.hpcl.titech.ac.jp> <20121004084916.GI9750@leitl.org> Message-ID: <506D5DB5.8000905@necom830.hpcl.titech.ac.jp> Eugen Leitl wrote: > My (minor) beef with it is that while you offload most of > heavy lifting to photonics you still use electronics and > lookup. Because for non linear operations, electronics is a lot better than so linear photonics w.r.t. speed, power, size etc. And, it's not my idea. See 'The "Staggering Switch": An Electronically Controlled Optical Packet Switch' by Zygmunt Haas, which mentioned "almost all optical" in 1993. > It is however reasonably easy to do everything > at effectively L2 with a photonic crossbar if you encode > geography in the headers (you have a direct proximity > metric on your link slots). How can you say BGP, then? > (You can actually prototype this with Ethernet MACs, > as 2^48 in square meters happens to be half the surface > area of the Earth http://www.wolframalpha.com/input/?i=2^48+m^2 > So MAC collisions are not very probable, if distributed > optimally ;) The problem with large number (beyond size of CAM with reasonable power consumption) of MAC is that hash table is necessary, which means route look up time is not bounded, which means fiber delay lines can not be used. Thousands of MAC addresses in a small L2 WAN is fine, except that BGP does not work. > If you do it in optics the protocol is completely different > from IPv4/IPv6, What I have shown is that what will be completely different will be L2. IPv4 uber alles. Masataka Ohta From tom.taylor.stds at gmail.com Thu Oct 4 14:16:00 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Thu, 04 Oct 2012 10:16:00 -0400 Subject: Dropping IPv6 Fragments Message-ID: <506D9A20.1070604@gmail.com> Who drops IPv6 fragments in their network, under what circumstances? Tom Taylor From saku at ytti.fi Thu Oct 4 14:20:58 2012 From: saku at ytti.fi (Saku Ytti) Date: Thu, 4 Oct 2012 17:20:58 +0300 Subject: Dropping IPv6 Fragments In-Reply-To: <506D9A20.1070604@gmail.com> References: <506D9A20.1070604@gmail.com> Message-ID: <20121004142058.GA19770@pob.ytti.fi> On (2012-10-04 10:16 -0400), Tom Taylor wrote: > Who drops IPv6 fragments in their network, under what circumstances? No one who offers working IP connections. Dropping IPv6 fragments against your control-plane, that is another discussion, but dropping them in transit would be short-lived exercise. -- ++ytti From tom.taylor.stds at gmail.com Thu Oct 4 14:25:46 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Thu, 04 Oct 2012 10:25:46 -0400 Subject: Dropping IPv6 Fragments In-Reply-To: <20121004142058.GA19770@pob.ytti.fi> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> Message-ID: <506D9C6A.9050101@gmail.com> On 04/10/2012 10:20 AM, Saku Ytti wrote: > On (2012-10-04 10:16 -0400), Tom Taylor wrote: > >> Who drops IPv6 fragments in their network, under what circumstances? > > No one who offers working IP connections. > > Dropping IPv6 fragments against your control-plane, that is another > discussion, but dropping them in transit would be short-lived exercise. > Let's talk control plane, then. Under what circumstances do fragments get dropped? From sander at steffann.nl Thu Oct 4 14:26:45 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 4 Oct 2012 16:26:45 +0200 Subject: Dropping IPv6 Fragments In-Reply-To: <20121004142058.GA19770@pob.ytti.fi> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> Message-ID: <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> Hi, >> Who drops IPv6 fragments in their network, under what circumstances? > > No one who offers working IP connections. > > Dropping IPv6 fragments against your control-plane, that is another > discussion, but dropping them in transit would be short-lived exercise. Depends on where you are looking. In the core network dropping fragments is not that common AFAIK. The closer you get to the edge the more common it might become... - Sander From rdobbins at arbor.net Thu Oct 4 14:36:28 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 4 Oct 2012 14:36:28 +0000 Subject: Dropping IPv6 Fragments In-Reply-To: <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> Message-ID: <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: > The closer you get to the edge the more common it might become... iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure. As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic. There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From joelja at bogus.com Thu Oct 4 14:58:36 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 04 Oct 2012 07:58:36 -0700 Subject: Dropping IPv6 Fragments In-Reply-To: <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> Message-ID: <506DA41C.70800@bogus.com> On 10/4/12 7:36 AM, Dobbins, Roland wrote: > On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: > >> The closer you get to the edge the more common it might become... > iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure. > > As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic. > > There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis. So the thing I'd note is that stateless IPV6 ACLs or load balancing provide you with an interesting problem since a fragment does not contain the headers beyond the required unfragmentable headers. it is possible but unlikely that the fragment will hash into the same bucket in a stateless load balancer (using what's left of 5-tuple). Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not. I would have to reassemble the packet (which isn't going to happen in the place where the stateless acl is applied) prior to being able to decide to pass it or not (or just pass fragments through that acl). > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From joelja at bogus.com Thu Oct 4 15:15:29 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 04 Oct 2012 08:15:29 -0700 Subject: IPv4 address length technical design In-Reply-To: <737E51D7-DCD8-4423-BF7F-B910EAB23314@xs4all.nl> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> <20121003T191621Z@localhost> <737E51D7-DCD8-4423-BF7F-B910EAB23314@xs4all.nl> Message-ID: <506DA811.4010704@bogus.com> On 10/4/12 1:31 AM, Marco Hogewoning wrote: > On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote: > >> IEEE 802 was expected to provide unique numbers for all computers ever built. >> >> Internet was expected to provide unique numbers for all computers actively on the network. >> >> Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. > Which brings the question, are we expected to ever run out of the 48 bits for mac-addresses? Of course there are exceptions, but in most cases you can probably start recycling them after a certain period. And that period could even become shorter over time, I mean what are the chances you find a iPhone 1 in your network these days? The IEEE/RAC regards the consistent enforcement of these restrictions as a fundamental and realistic basis for ensuring longevity of the EUI-48 identifier capability, with a target lifetime of 100 years for existing applications using EUI-48 identifiers. http://standards.ieee.org/develop/regauth/tut/eui.pdf > Marco > From rdobbins at arbor.net Thu Oct 4 15:15:45 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 4 Oct 2012 15:15:45 +0000 Subject: Dropping IPv6 Fragments In-Reply-To: <506DA41C.70800@bogus.com> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> <506DA41C.70800@bogus.com> Message-ID: <738A1605-76E7-4A3E-B42B-CEE26A0A7E09@arbor.net> On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote: > Likewise with the acl I have the property that the initial packet has > all the info in it while the fragment does not. For iACLs, just filter non-initial fragments directed to infrastructure IPs. Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From kas at kas.no Thu Oct 4 15:18:00 2012 From: kas at kas.no (Knut A. Syed) Date: Thu, 04 Oct 2012 17:18:00 +0200 Subject: Technical contact at XO/Concentric Message-ID: <506DA8A8.5020805@kas.no> Hi, If anyone from XO/Concentric is on on the list or anyone has a technical contact who can help with connectivity issues to their hosted Web-sites, please pass this along to the right person/team or respond to me off-list. Some of our customers are having problems connecting to Web-services hosted by XO/Concentric. The problem is limited to customers within a certain /17 allocation we have (82.134.0.0/17). Ping and connections to the SMTP-service on the same destination IP are fine. But when the customers try to connect to the HTTP-service tcpdumps shows that no packets are returned. We have tried Customer Care to no help. TIA! Kind Regards, Knut A. Syed From joelja at bogus.com Thu Oct 4 15:27:41 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 04 Oct 2012 08:27:41 -0700 Subject: Dropping IPv6 Fragments In-Reply-To: <738A1605-76E7-4A3E-B42B-CEE26A0A7E09@arbor.net> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> <506DA41C.70800@bogus.com> <738A1605-76E7-4A3E-B42B-CEE26A0A7E09@arbor.net> Message-ID: <506DAAED.3010204@bogus.com> On 10/4/12 8:15 AM, Dobbins, Roland wrote: > On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote: > >> Likewise with the acl I have the property that the initial packet has >> all the info in it while the fragment does not. > For iACLs, just filter non-initial fragments directed to infrastructure IPs. Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments. Yeah, that's more or less what we said in RFC 6192. That said as the network operator of a content provider I have more devices in my portfolio than just backbone routers. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From bjorn at leffler.org Thu Oct 4 15:39:46 2012 From: bjorn at leffler.org (Bjorn Leffler) Date: Thu, 4 Oct 2012 11:39:46 -0400 Subject: IPv4 address length technical design In-Reply-To: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> Message-ID: On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell wrote: > > Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? I've heard Vint Cerf say this himself, but here's a written reference for you. They had just finished building arpanet, which was expensive to build. Hence why they estimated two networks per country. http://www.domainpulse.com/2012/06/06/world-ipv6-day/ When developing IPv4, Cerf said that he and Bob Kahn ?estimated that there might be two national-scale packet networks per country and perhaps 128 countries able to build them, so 8 bits sufficed for 256 network identifiers. Twenty-four bits allowed for up to 16 million hosts. At that time, hosts were big, expensive time-sharing systems, so 16 million seemed like a lot. We did consider variable length and 128-bit addressing in 1977 but decided that this would be too much overhead for the relatively low-speed lines (50 kilobits per second). I thought this was still an experiment and that if it worked we would then design a production version. From joelja at bogus.com Thu Oct 4 17:17:44 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 04 Oct 2012 10:17:44 -0700 Subject: 100.100.0.0/24 Message-ID: <506DC4B8.30208@bogus.com> http://bgp.he.net/net/100.100.0.0/24#_bogon A surprising number of large transit ASes appear to be more than willing to accept this prefix from AS4847. I'd be a lot happier if there were fewer. thanks joel From merike at doubleshotsecurity.com Thu Oct 4 17:42:31 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Thu, 4 Oct 2012 10:42:31 -0700 Subject: Dropping IPv6 Fragments In-Reply-To: <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> Message-ID: On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote: > > On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: > >> The closer you get to the edge the more common it might become... > > iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure. > > As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic. +1 > There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis. Same misconception as ICMP is bad....historical artifact from attacks in early 90's that just perpetuate in mythical best practice. I was just investigating with varying folks whether they also log v6 fragment filtering exceptions and whether anyone has seen anything 'interesting' :) Nothing interesting yet. I'm co-authoring a doc in IETF which consolidates v6 security practices and looks to provide info for what current BCP is as folks are more actively deploying v6. Was just at RIPE to get input from that operator community and want to solicit input here as well. Doc is at: http://tools.ietf.org/html/draft-ietf-opsec-v6-00 Feedback on mailing list would be great: https://www.ietf.org/mailman/listinfo/opsec but, if easier to send email to authors just do so directly and we'll incorporate and vet appropriately. All 3 authors follow quite a few *NOG lists and have been involved in deployments so hopefully this can help educate the less informed. - merike > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From surfer at mauigateway.com Thu Oct 4 17:42:30 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Oct 2012 10:42:30 -0700 Subject: 100.100.0.0/24 Message-ID: <20121004104230.B6A8DC9E@m0005311.ppops.net> --- joelja at bogus.com wrote: From: joel jaeggli http://bgp.he.net/net/100.100.0.0/24#_bogon A surprising number of large transit ASes appear to be more than willing to accept this prefix from AS4847. I'd be a lot happier if there were fewer. ------------------------------------------------- To save others the time of looking it up... :-) http://tools.ietf.org/html/rfc6598 scott From dot at dotat.at Thu Oct 4 18:19:43 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 4 Oct 2012 19:19:43 +0100 Subject: IPv4 address length technical design In-Reply-To: <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> Message-ID: Owen DeLong wrote: > > Once host identifiers are no longer dependent on or related to topology, > there's no reason a reasonable fixed-length cannot suffice. Host identities should be cryptographic hashes of public keys, so you have to support algorithm agility, which probably implies variable length. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Valdis.Kletnieks at vt.edu Thu Oct 4 18:25:47 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Oct 2012 14:25:47 -0400 Subject: IPv4 address length technical design In-Reply-To: Your message of "Thu, 04 Oct 2012 09:57:34." References: Message-ID: <15424.1349375147@turing-police.cc.vt.edu> On Thu, 04 Oct 2012 09:57:34, Johnny Eriksson said: > Valdis.Kletnieks at vt.edu wrote: > > > And the -10s and -20s were the major reason RFCs refer to octets > > rather than bytes, as they had a rather slippery notion of "byte" > > (anywhere from 6 to 9 bits, often multiple sizes used *in the > > same program*). > > Not quite correct. Anywhere from 1 to 36 bits, and not spanning > a 36-bit word boundary. Essentialy what is now known as a bit field. Right - but in actual programming practice, code tended to distinguish between a "byte" and "N bit wide field of flags or whatever". And bytes as character storage ran from 6 to 9 bits depending on the charset in use. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Oct 4 18:34:22 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Oct 2012 14:34:22 -0400 Subject: 100.100.0.0/24 In-Reply-To: <506DC4B8.30208@bogus.com> References: <506DC4B8.30208@bogus.com> Message-ID: On Thu, Oct 4, 2012 at 1:17 PM, joel jaeggli wrote: > http://bgp.he.net/net/100.100.0.0/24#_bogon > > A surprising number of large transit ASes appear to be more than willing to > accept this prefix from AS4847. that took longer than expected. the internet has failed my expectations. From fernando at gont.com.ar Thu Oct 4 19:15:46 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 04 Oct 2012 15:15:46 -0400 Subject: Dropping IPv6 Fragments In-Reply-To: <506DA41C.70800@bogus.com> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> <506DA41C.70800@bogus.com> Message-ID: <506DE062.1020207@gont.com.ar> Hi, Joel, On 10/04/2012 10:58 AM, joel jaeggli wrote: > So the thing I'd note is that stateless IPV6 ACLs or load balancing > provide you with an interesting problem since a fragment does not > contain the headers beyond the required unfragmentable headers. In the real world, such packets are not legitimate, so feel free to drop them. draft-ietf-6man-oversized-header-chain formally addresses this issue. > Likewise with the acl I have the property that the initial packet has > all the info in it while the fragment does not. You're talking about initial-fragment vs non-initial fragments? -- If so, in theory *both* might be missing the upper layer information. IN practice, the first-fragment won't. If it does, feel free to drop it. Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jlappa at gmail.com Thu Oct 4 19:20:51 2012 From: jlappa at gmail.com (Joseph Lappa) Date: Thu, 4 Oct 2012 15:20:51 -0400 Subject: TOR Question Message-ID: Hi, There was a thread on Nanog in January about TOR and deep buffers (http://seclists.org/nanog/2012/Jan/966). I have a follow-up, related question. Has anyone used a TOR switch to aggregate connections to from major network providers? For example, 2 or more 10GE ingress connections (pick your favorite CDNs) into one 10GE egress back to our router (which is at a remote location). We are worried that queue buffers are too small to handle the traffic going to the egress port. Thanks, Joe Lappa From owen at delong.com Thu Oct 4 19:49:03 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Oct 2012 12:49:03 -0700 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <995CA426-890A-4077-B90E-7BCE9A4712A9@delong.com> Message-ID: <1906DD40-1645-4B27-B80B-FA55ACC23D54@delong.com> On Oct 4, 2012, at 11:19 AM, Tony Finch wrote: > Owen DeLong wrote: >> >> Once host identifiers are no longer dependent on or related to topology, >> there's no reason a reasonable fixed-length cannot suffice. > > Host identities should be cryptographic hashes of public keys, so you have > to support algorithm agility, which probably implies variable length. > No, they really shouldn't, but I understand why some security zealots think that's a good idea. Owen From bill at herrin.us Thu Oct 4 20:00:13 2012 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2012 16:00:13 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R wrote: > On Oct 3, 2012, at 6:49 PM, Jimmy Hess wrote: >> In 100 years, when we start to run out of IPv6 addresses, possibly we >> will have learned our lesson and done two things: >> >> (1) Stopped mixing the Host identification and the Network >> identification into the same bit field; instead every packet gets a >> source network address, destination network address, AND an >> additional tuple of Source host address, destination host >> address; residing in completely separate address spaces, with no >> "Netmasks", "Prefix lengths", or other comingling of network >> addresses and host address spaces. >> >> And >> (2) The new protocol will use variable-length address for the Host >> portion, such as used in the addresses of CLNP, with a convention of >> a specified length, instead of a hardwired specific limit that comes >> from using a permanently fixed-width field. > > I suggest that the DNS name space should be considered to be > an "hierarchical host address space" thus satisfying (1) and making (2) moot. I'd suggest that too, but we'd have to throw out TCP, UDP and a good chunk of the BSD sockets API to get there. Or did you mean use DNS as it fits in the current system, which doesn't actually satisfy (1) at all since the layer 4 protocols continue to build the connection identity from the layer 3 network identity instead of the external host/service identity. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From james.cutler at consultant.com Thu Oct 4 20:17:06 2012 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 4 Oct 2012 16:17:06 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: On Oct 4, 2012, at 4:00 PM, William Herrin wrote: > On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R > wrote: >> On Oct 3, 2012, at 6:49 PM, Jimmy Hess wrote: >>> In 100 years, when we start to run out of IPv6 addresses, possibly we >>> will have learned our lesson and done two things: >>> >>> (1) Stopped mixing the Host identification and the Network >>> identification into the same bit field; instead every packet gets a >>> source network address, destination network address, AND an >>> additional tuple of Source host address, destination host >>> address; residing in completely separate address spaces, with no >>> "Netmasks", "Prefix lengths", or other comingling of network >>> addresses and host address spaces. >>> >>> And >>> (2) The new protocol will use variable-length address for the Host >>> portion, such as used in the addresses of CLNP, with a convention of >>> a specified length, instead of a hardwired specific limit that comes >>> from using a permanently fixed-width field. >> >> I suggest that the DNS name space should be considered to be >> an "hierarchical host address space" thus satisfying (1) and making (2) moot. > > I'd suggest that too, but we'd have to throw out TCP, UDP and a good > chunk of the BSD sockets API to get there. > > Or did you mean use DNS as it fits in the current system, which > doesn't actually satisfy (1) at all since the layer 4 protocols > continue to build the connection identity from the layer 3 network > identity instead of the external host/service identity. > > Regards, > Bill Herrin Yes. Why does the connection identity have to include the host identifier. Is that not a problem under the control of applications? From bill at herrin.us Thu Oct 4 20:34:17 2012 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2012 16:34:17 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Oct 4, 2012 at 4:17 PM, Cutler James R wrote: > On Oct 4, 2012, at 4:00 PM, William Herrin wrote: >> On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R >> wrote: >> Or did you mean use DNS as it fits in the current system, which >> doesn't actually satisfy (1) at all since the layer 4 protocols >> continue to build the connection identity from the layer 3 network >> identity instead of the external host/service identity. >> > Why does the connection identity have to include the host identifier. Is that not a problem under the control of applications? Nope. It's under the control of the layer 4 protocol, generally TCP or UDP, and implemented at the OS level. For example, in TCP the connection identity is composed of the source and destination IP addresses and port numbers. Together, these 96 bits of information comprise the unique identity of that TCP connection which the OS matches to the socket number the application interacts with. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marka at isc.org Thu Oct 4 21:14:07 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Oct 2012 07:14:07 +1000 Subject: Dropping IPv6 Fragments In-Reply-To: Your message of "Thu, 04 Oct 2012 10:42:31 MST." References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> Message-ID: <20121004211407.96FEE2895C38@drugs.dv.isc.org> In message , Merik e Kaeo writes: > > On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote: > > >=20 > > On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: > >=20 > >> The closer you get to the edge the more common it might become... > >=20 > > iACLs should be implemented at the network edge to drop all IPv4 and = > IPv6 traffic - including non-initial fragments - directed towards = > point-to-point links, loopbacks, and other internal infrastructure with = > exceptions made for cases where there's a legitimate need for sources = > outside your network to be able to communicate with your infrastructure. > >=20 > > As mentioned previously on the thread, this has nothing to do with = > transit data-plane traffic, which should be left untouched unless it's = > specifically classified as attack traffic or other undesirable traffic. > > +1 > > > There's an apparently common misperception that fragmented traffic is = > somehow bad. It isn't. It's normal, under most circumstances. Protect = > your infrastructure proactively, deal with anything else on a = > case-by-case basis. > > Same misconception as ICMP is bad....historical artifact from attacks in = > early 90's that just perpetuate in mythical best practice. =20 And it really hurts modern DNS where UDP responses often exceed Ethernet MTU. For IPv6 UDP DNS responses are often fragmented at 1280 to prevent PMTUD being needed. For IPv4 PMTUD should be off if your vendor followed the RFC's (know exception are Linux and Solaris boxes). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Thu Oct 4 22:45:17 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 05 Oct 2012 07:45:17 +0900 Subject: Dropping IPv6 Fragments In-Reply-To: <506DE062.1020207@gont.com.ar> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> <506DA41C.70800@bogus.com> <506DE062.1020207@gont.com.ar> Message-ID: <506E117D.5090301@necom830.hpcl.titech.ac.jp> Fernando Gont wrote: > In the real world, such packets are not legitimate, so feel free to drop > them. draft-ietf-6man-oversized-header-chain formally addresses this issue. The ID misses the problem of 4->6 translator. That is, though the ID state: Entire IPv6 header chain: All protocol headers starting from the fixed IPv6 header till (and including) the upper layer protocol header (TCP, UDP, etc. -- assuming there is one of those), the translator may not have any knowledge on how long "the upper layer protocol header" is. Thus, the requirement of the ID is impossible to enforce. Moreover, a 68B IPv4 fragment of some packet with 60B upper layer protocol header can not be translated to IPv6. In theory, with 60B IPv4 header, a 68B IPv4 fragment can't even contain an entire TCP header. So, the requirement of the ID should be to require only the first 8B of the upper layer protocol header. All the (pseudo) transport protocols working over IPv4 is designed to identify transport identity with the first 8B of transport headers. >> Likewise with the acl I have the property that the initial packet has >> all the info in it while the fragment does not. > > You're talking about initial-fragment vs non-initial fragments? -- If > so, in theory *both* might be missing the upper layer information. Yes, that is one of an annoying point of IPv6. Masataka Ohta From bzs at world.std.com Thu Oct 4 23:36:19 2012 From: bzs at world.std.com (Barry Shein) Date: Thu, 4 Oct 2012 19:36:19 -0400 Subject: IPv4 address length technical design In-Reply-To: <20121004064745.GB9750@leitl.org> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> Message-ID: <20590.7539.491575.455977@world.std.com> In Singapore in June 2011 I gave a talk at HackerSpaceSG about just doing away with IP addresses entirely, and DNS. Why not just use host names directly as addresses? Bits is bits, FQDNs are integers because, um, bits is bits. They're even structured so you can route on the network portion etc. Routers themselves could hash them into some more efficient form for table management but that wouldn't be externally visible. I did suggest a standard for such hashing just to help with debugging etc but it'd only be a suggestion or perhaps common display format. About the only obvious objection, other than vague handwaves about compute efficiency, is it would potentially make packets a lot longer in the worst case scenario, longer than common MTUs tho not much longer unless we also allow a lengthening of host name max, 1024 right now I believe? So 2K max for src/dest and whatever other overhead payload you need, not unthinkable. OTOH, it just does away with DNS entirely which is some sort of savings. There are obviously some more details required, this email is not a replacement for a set of RFCs! -- -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 marka at isc.org Thu Oct 4 23:50:03 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Oct 2012 09:50:03 +1000 Subject: IPv4 address length technical design In-Reply-To: Your message of "Thu, 04 Oct 2012 19:36:19 -0400." <20590.7539.491575.455977@world.std.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <20590.7539.491575.455977@world.std.com> Message-ID: <20121004235004.0C5542896C3C@drugs.dv.isc.org> In message <20590.7539.491575.455977 at world.std.com>, Barry Shein writes: > > In Singapore in June 2011 I gave a talk at HackerSpaceSG about just > doing away with IP addresses entirely, and DNS. > > Why not just use host names directly as addresses? Bits is bits, FQDNs > are integers because, um, bits is bits. They're even structured so you > can route on the network portion etc. It's the worst idea I've heard in a long time. Names have nothing to do with physical location or how you reach a machine. > Routers themselves could hash them into some more efficient form for > table management but that wouldn't be externally visible. I did > suggest a standard for such hashing just to help with debugging etc > but it'd only be a suggestion or perhaps common display format. > > About the only obvious objection, other than vague handwaves about > compute efficiency, is it would potentially make packets a lot longer > in the worst case scenario, longer than common MTUs tho not much > longer unless we also allow a lengthening of host name max, 1024 right > now I believe? So 2K max for src/dest and whatever other overhead > payload you need, not unthinkable. > > OTOH, it just does away with DNS entirely which is some sort of > savings. > > There are obviously some more details required, this email is not a > replacement for a set of RFCs! > > -- > -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* > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From george.herbert at gmail.com Thu Oct 4 23:52:56 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 4 Oct 2012 16:52:56 -0700 Subject: IPv4 address length technical design In-Reply-To: <20590.7539.491575.455977@world.std.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <20590.7539.491575.455977@world.std.com> Message-ID: On Thu, Oct 4, 2012 at 4:36 PM, Barry Shein wrote: > > In Singapore in June 2011 I gave a talk at HackerSpaceSG about just > doing away with IP addresses entirely, and DNS. > > Why not just use host names directly as addresses? Bits is bits, FQDNs > are integers because, um, bits is bits. They're even structured so you > can route on the network portion etc. > > Routers themselves could hash them into some more efficient form for > table management but that wouldn't be externally visible. I did > suggest a standard for such hashing just to help with debugging etc > but it'd only be a suggestion or perhaps common display format. > > About the only obvious objection, other than vague handwaves about > compute efficiency, is it would potentially make packets a lot longer > in the worst case scenario, longer than common MTUs tho not much > longer unless we also allow a lengthening of host name max, 1024 right > now I believe? So 2K max for src/dest and whatever other overhead > payload you need, not unthinkable. > > OTOH, it just does away with DNS entirely which is some sort of > savings. > > There are obviously some more details required, this email is not a > replacement for a set of RFCs! You'd still need DNS for non-A/PTR types of records. This scheme fails miserably in one practical manner - it's impossible to tell people far away from the source of a DNS / name domain's authority that a.foo.com and b.foo.com are in the UK and c.foo.com and d.foo.com are in Japan. With IP addresses, heirarchical blocks make routing trivial. Name based routing is ... seems hard, or insanely hard for "real complex networks" as opposed to trivial end user types of situations. Possibly unworkably hard. One could rename things such as having a.location.foo.com but you still encounter the problem that you have to propogate knowledge of where location.foo.com is further out into the universe. Nice troll and/or wild-crazy-idea though. -- -george william herbert george.herbert at gmail.com From me at anuragbhatia.com Fri Oct 5 00:10:02 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 05 Oct 2012 05:40:02 +0530 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> Message-ID: <506E255A.1000401@anuragbhatia.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 05 October 2012 12:04 AM, Christopher Morrow wrote: > On Thu, Oct 4, 2012 at 1:17 PM, joel jaeggli wrote: >> http://bgp.he.net/net/100.100.0.0/24#_bogon >> >> A surprising number of large transit ASes appear to be more than willing to >> accept this prefix from AS4847. > > that took longer than expected. > the internet has failed my expectations. > I learnt to use whois for such strange results! :) anurag at laptop:~$ whois 100.64.0.0 # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=100.64.0.0?showDetails=true&showARIN=false&ext=netref2 # NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED NetHandle: NET-100-64-0-0-1 Parent: NET-100-0-0-0-0 NetType: IANA Special Use Comment: This block is used as Shared Address Space. Traffic from these addresses does not come from IANA. IANA has simply reserved these numbers in its database and does not use or operate them. We are not the source of activity you may see on logs or in e-mail records. Please refer to http://www.iana.org/abuse/ Comment: Comment: Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when addresses are identical on two different interfaces. Comment: Comment: This block was assigned by the IETF in the Best Current Practice document, Comment: RFC 6598 which can be found at: Comment: http://tools.ietf.org/html/rfc6598 RegDate: 2012-03-13 Updated: 2012-04-23 Ref: http://whois.arin.net/rest/net/NET-100-64-0-0-1 - -- Anurag Bhatia http://anuragbhatia.com Twitter: @anurag_bhatia Skype: anuragbhatia.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQbiVaAAoJEPnIYygGLJNaV18H/Rg/TJiMhh6QbYHX04JFLQ1V UOd0ihW128qpKllFMuqmwkeBFF2psPqrSdCBGqk+J1CQtgmcgwPNUaebVzoijaa/ kuPBMJNod6DhIiwKSZlkWkL5cF7buhh+E0neT4LMHsE/qVxgXEYZF/Z0OWR1L71e 38xw8Nx2javtXcBlpPbMDriFekmv4B1tSw9R4aHDJolquYmjZzBpOSj8EAX5hYLW vj7nc6SYp5lGuwgbSYCwPZvIXN0Olt/puuabeVFRXbwKWml/wScAunBIbCoP/n2G gT1MdVpcMnsBj1ZJC/fIy70Wlu/6d7z4hq8OMosLXZ3ayrmCU0QAslr6GUOhYz0= =RUOc -----END PGP SIGNATURE----- From jra at baylink.com Fri Oct 5 04:23:18 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Oct 2012 00:23:18 -0400 (EDT) Subject: IPv4 address length technical design In-Reply-To: <20590.7539.491575.455977@world.std.com> Message-ID: <6862864.28365.1349410998597.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > In Singapore in June 2011 I gave a talk at HackerSpaceSG about just > doing away with IP addresses entirely, and DNS. > > Why not just use host names directly as addresses? Bits is bits, FQDNs > are integers because, um, bits is bits. They're even structured so you > can route on the network portion etc. > > Routers themselves could hash them into some more efficient form for > table management but that wouldn't be externally visible. I did > suggest a standard for such hashing just to help with debugging etc > but it'd only be a suggestion or perhaps common display format. And Whacky Weekend begins early. Jim? Jim Fleming? How'd you break into Barry's email account? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From randy at psg.com Fri Oct 5 12:08:56 2012 From: randy at psg.com (Randy Bush) Date: Fri, 05 Oct 2012 05:08:56 -0700 Subject: 100.100.0.0/24 In-Reply-To: <506DC4B8.30208@bogus.com> References: <506DC4B8.30208@bogus.com> Message-ID: > http://bgp.he.net/net/100.100.0.0/24#_bogon > > A surprising number of large transit ASes appear to be more than willing > to accept this prefix from AS4847. a private address space leak? and propagated. i am deeply shocked. wtf did people think would happen? randy From swmike at swm.pp.se Fri Oct 5 12:27:39 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 5 Oct 2012 14:27:39 +0200 (CEST) Subject: Dropping IPv6 Fragments In-Reply-To: <506D9A20.1070604@gmail.com> References: <506D9A20.1070604@gmail.com> Message-ID: On Thu, 4 Oct 2012, Tom Taylor wrote: > Who drops IPv6 fragments in their network, under what circumstances? People who run 7600 with SUP720 and who hasn't turned on a certain command. #platform ipv6 acl fragment hardware ? drop Drop IPv6 fragments at hardware forward Forward IPv6 fragments at hardware -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Fri Oct 5 12:29:54 2012 From: joelja at bogus.com (joel jaeggli) Date: Fri, 05 Oct 2012 05:29:54 -0700 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> Message-ID: <506ED2C2.7090706@bogus.com> On 10/5/12 5:08 AM, Randy Bush wrote: >> http://bgp.he.net/net/100.100.0.0/24#_bogon >> >> A surprising number of large transit ASes appear to be more than willing >> to accept this prefix from AS4847. > a private address space leak? and propagated. i am deeply shocked. > > wtf did people think would happen? I'm unsurprised that not all filters are in place, more or less where they weren't however is another matter. by all accounts this has been advertised since 8/24. > randy > From bill at herrin.us Fri Oct 5 13:06:58 2012 From: bill at herrin.us (William Herrin) Date: Fri, 5 Oct 2012 09:06:58 -0400 Subject: IPv4 address length technical design In-Reply-To: <20590.7539.491575.455977@world.std.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <20590.7539.491575.455977@world.std.com> Message-ID: On Thu, Oct 4, 2012 at 7:36 PM, Barry Shein wrote: > In Singapore in June 2011 I gave a talk at HackerSpaceSG about just > doing away with IP addresses entirely, and DNS. > About the only obvious objection, other than vague handwaves about > compute efficiency, is it would potentially make packets a lot longer What portion of your audience would you say took it at face value without realizing they'd been trolled? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From benno at NLnetLabs.nl Fri Oct 5 13:17:33 2012 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 05 Oct 2012 15:17:33 +0200 Subject: Dropping IPv6 Fragments In-Reply-To: <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> References: <506D9A20.1070604@gmail.com> <20121004142058.GA19770@pob.ytti.fi> <3A0C0104-8118-4CEE-89D2-98815ABFBD93@steffann.nl> <8B29D89C-9DBC-4BDD-BA1A-D2FD9421BFCF@arbor.net> Message-ID: <506EDDED.4010407@NLnetLabs.nl> On 10/04/2012 04:36 PM, Dobbins, Roland wrote: > > On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: > >> The closer you get to the edge the more common it might become... > > iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure. > > As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic. > > There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis. Two students worked on a project in June to measure fragment dropping in IPv6 (and IPv4) using the RIPE Atlas probe infrastructure. Their findings are consistent with Sander's remark. The core seems to do fine, but at the edges it is observed that some middleboxes/CPEs do drop IPv6 fragments. I think this is consistent with the remarks of Joel and Roland earlier on Cisco/Juniper iACL vs. simpler boxes in your network. You can find the report at http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf. Best, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From shannon at more.net Fri Oct 5 14:18:10 2012 From: shannon at more.net (Spurling, Shannon) Date: Fri, 5 Oct 2012 14:18:10 +0000 Subject: IPv4 address length technical design In-Reply-To: References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <20590.7539.491575.455977@world.std.com> Message-ID: I had toyed with the idea that maybe we needed an identity based routing system. Addressing doesn't change because it's the physical map of the network. Instead what you need is a set of identity "banking" servers, either arranged by organization or contract, that hold a public key and that your workstations and servers update with their current location. That would be similar to the current DNS infrastructure. When you wish to transact with one of these servers, you use the DNS like identity to retrieve the current location, and send a signed connection request via TCP or UDP. The remote end received an authenticated request that you can confirm using your identity and public key. You don't have to encrypt the contents of the packet, but you could if you needed to. If an address changes, that device could send a signed update indicating the IP change to all currently opened sockets and it's authoritative identity server. I know it's kind of rough, but it would take all this complexity and put it back in the workstation stack. Everybody is lowering their DNS TTL's to nothing anymore to support dynamic DNS. There is a big push to virtualize and fragment the IP address scheme to support IP mobility, which flies in the face of good network management. Not to mention how IP mobility also enables man in the middle to become a serious reality. And all the router vendors are pushing for more features, instead of doing what they are supposed to do better. I think a concept like this could help on several levels. It just seems like something different needs to be done. S - -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, October 05, 2012 8:07 AM To: Barry Shein Cc: nanog at nanog.org Subject: Re: IPv4 address length technical design On Thu, Oct 4, 2012 at 7:36 PM, Barry Shein wrote: > In Singapore in June 2011 I gave a talk at HackerSpaceSG about just > doing away with IP addresses entirely, and DNS. > About the only obvious objection, other than vague handwaves about > compute efficiency, is it would potentially make packets a lot longer What portion of your audience would you say took it at face value without realizing they'd been trolled? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Fri Oct 5 15:07:45 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Oct 2012 11:07:45 -0400 Subject: 100.100.0.0/24 In-Reply-To: <506ED2C2.7090706@bogus.com> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> Message-ID: On Fri, Oct 5, 2012 at 8:29 AM, joel jaeggli wrote: > by all accounts this has been advertised since 8/24. space allocated: 2012-03-13 that's 5 months and 11 days too long. From jared at puck.nether.net Fri Oct 5 15:18:22 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 5 Oct 2012 11:18:22 -0400 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> Message-ID: <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> On Oct 5, 2012, at 11:07 AM, Christopher Morrow wrote: > On Fri, Oct 5, 2012 at 8:29 AM, joel jaeggli wrote: > >> by all accounts this has been advertised since 8/24. > > space allocated: 2012-03-13 > that's 5 months and 11 days too long. I suspect not everyone has updated their 'bogon' filters. I found a very minor gap in our filters, we are working on correcting it. - Jared From Dave.Siegel at level3.com Fri Oct 5 15:23:33 2012 From: Dave.Siegel at level3.com (Siegel, David) Date: Fri, 5 Oct 2012 15:23:33 +0000 Subject: IPv4 address length technical design In-Reply-To: <20590.7539.491575.455977@world.std.com> References: <506C9D3D.8090301@dcrocker.net> <28577766.28121.1349298594756.JavaMail.root@benjamin.baylink.com> <28390.1349305160@turing-police.cc.vt.edu> <20121004064745.GB9750@leitl.org> <20590.7539.491575.455977@world.std.com> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40@W8USSFJ204.ams.gblxint.com> Wouldn't that implicate the routing system to have, in essence, one routing entry for every host on the network? That would be the moral equivalent to just dropping down to a global ethernet fabric to replace IP and using mac addresses for routing. I'll give you one guess as to how well that would work. Dave -----Original Message----- From: Barry Shein [mailto:bzs at world.std.com] Sent: Thursday, October 04, 2012 5:36 PM To: nanog at nanog.org Subject: Re: IPv4 address length technical design In Singapore in June 2011 I gave a talk at HackerSpaceSG about just doing away with IP addresses entirely, and DNS. Why not just use host names directly as addresses? Bits is bits, FQDNs are integers because, um, bits is bits. They're even structured so you can route on the network portion etc. Routers themselves could hash them into some more efficient form for table management but that wouldn't be externally visible. I did suggest a standard for such hashing just to help with debugging etc but it'd only be a suggestion or perhaps common display format. About the only obvious objection, other than vague handwaves about compute efficiency, is it would potentially make packets a lot longer in the worst case scenario, longer than common MTUs tho not much longer unless we also allow a lengthening of host name max, 1024 right now I believe? So 2K max for src/dest and whatever other overhead payload you need, not unthinkable. OTOH, it just does away with DNS entirely which is some sort of savings. There are obviously some more details required, this email is not a replacement for a set of RFCs! -- -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 uwcableguy at gmail.com Fri Oct 5 15:24:18 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 5 Oct 2012 10:24:18 -0500 Subject: 100.100.0.0/24 In-Reply-To: <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> Message-ID: use this: http://www.team-cymru.org/Services/Bogons/bgp.html On Fri, Oct 5, 2012 at 10:18 AM, Jared Mauch wrote: > > On Oct 5, 2012, at 11:07 AM, Christopher Morrow wrote: > > > On Fri, Oct 5, 2012 at 8:29 AM, joel jaeggli wrote: > > > >> by all accounts this has been advertised since 8/24. > > > > space allocated: 2012-03-13 > > that's 5 months and 11 days too long. > > I suspect not everyone has updated their 'bogon' filters. I found a very > minor gap in our filters, we are working on correcting it. > > - Jared > From joelja at bogus.com Fri Oct 5 15:26:54 2012 From: joelja at bogus.com (joel jaeggli) Date: Fri, 05 Oct 2012 08:26:54 -0700 Subject: 100.100.0.0/24 In-Reply-To: <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> Message-ID: <506EFC3E.1090603@bogus.com> On 10/5/12 8:18 AM, Jared Mauch wrote: > On Oct 5, 2012, at 11:07 AM, Christopher Morrow wrote: > >> On Fri, Oct 5, 2012 at 8:29 AM, joel jaeggli wrote: >> >>> by all accounts this has been advertised since 8/24. >> space allocated: 2012-03-13 >> that's 5 months and 11 days too long. > I suspect not everyone has updated their 'bogon' filters. I found a very minor gap in our filters, we are working on correcting it. I would imagine though I am open to other interpreations that, the root cause of the leak lies there as well. > - Jared > From jared at puck.nether.net Fri Oct 5 15:28:54 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 5 Oct 2012 11:28:54 -0400 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> Message-ID: <97632A7E-0001-44AC-BF53-7143A0409D07@puck.nether.net> Our issue is the templates were updated except for all but one type of device. If you see issues with 2914 folks can ping me off-list. - jared On Oct 5, 2012, at 11:24 AM, Ben Bartsch wrote: > use this: > > http://www.team-cymru.org/Services/Bogons/bgp.html > > > On Fri, Oct 5, 2012 at 10:18 AM, Jared Mauch wrote: > > On Oct 5, 2012, at 11:07 AM, Christopher Morrow wrote: > > > On Fri, Oct 5, 2012 at 8:29 AM, joel jaeggli wrote: > > > >> by all accounts this has been advertised since 8/24. > > > > space allocated: 2012-03-13 > > that's 5 months and 11 days too long. > > I suspect not everyone has updated their 'bogon' filters. I found a very minor gap in our filters, we are working on correcting it. > > - Jared > From randy at psg.com Fri Oct 5 16:24:02 2012 From: randy at psg.com (Randy Bush) Date: Fri, 05 Oct 2012 09:24:02 -0700 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> Message-ID: >> by all accounts this has been advertised since 8/24. > space allocated: 2012-03-13 > that's 5 months and 11 days too long. no one noticed the other leaks From johnl at iecc.com Fri Oct 5 16:47:51 2012 From: johnl at iecc.com (John Levine) Date: 5 Oct 2012 16:47:51 -0000 Subject: IPv4 address length technical design In-Reply-To: <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40@W8USSFJ204.ams.gblxint.com> Message-ID: <20121005164751.50925.qmail@joyce.lan> In article <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40 at W8USSFJ204.ams.gblxint.com> you write: >Wouldn't that implicate the routing system to have, in essence, one routing entry for every host on the network? > >That would be the moral equivalent to just dropping down to a global ethernet fabric to replace IP and using mac addresses for >routing. I'll give you one guess as to how well that would work. It works well for the 12 computers in my home office. Therefore it's a solved problem and trivial to implement. HTH, HAND, &c. John From bzs at world.std.com Fri Oct 5 17:30:23 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 5 Oct 2012 13:30:23 -0400 Subject: IPv4 address length technical design In-Reply-To: <6862864.28365.1349410998597.JavaMail.root@benjamin.baylink.com> References: <20590.7539.491575.455977@world.std.com> <6862864.28365.1349410998597.JavaMail.root@benjamin.baylink.com> Message-ID: <20591.6447.608649.221847@world.std.com> Don't change anything! That would...change things! Obviously my idea to use the host name directly as a src/dest address rather than convert it to an integer is not a small, incremental change. It's more in the realm of a speculative proposal. But I'm not sure that arguing that our string of bits (e.g., ipv6) is inherently superior to your proposed string of bits (a host name) is an immediately compelling objection. The objection which puzzles me the most is the implication that a numeric address locates a host or network directly or geographically rather than, as I understood it, by the tuple (address,route). Well, geographically? Since when, except at the very end of the routing sequence? "First they ignore you, then they ridicule you, then they fight you, then you win" -- Mahatma Gandhi -- -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 jra at baylink.com Fri Oct 5 18:06:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Oct 2012 14:06:08 -0400 (EDT) Subject: IPv4 address length technical design In-Reply-To: <20591.6447.608649.221847@world.std.com> Message-ID: <29525376.28501.1349460368640.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > Don't change anything! That would...change things! Your man; he is made of straw. :-) > Obviously my idea to use the host name directly as a src/dest address > rather than convert it to an integer is not a small, incremental > change. It's more in the realm of a speculative proposal. Speculative is orthogonal to small or incremental; they are different measurement axes. This is also true of the difference between addresses and names. Addresses are an engineering artifact; names are a business/administrative artifact. *The entire point* of DNS vs IP is to uncouple those; necessary changes in the engineering artifact *MUST not* cause changes in the business artifact. > But I'm not sure that arguing that our string of bits (e.g., ipv6) is > inherently superior to your proposed string of bits (a host name) is > an immediately compelling objection. And, unsurprisingly, no one made an argument that trivial. To the extent you think we did, I think we were merely giving you the benefit of the doubt of already understanding this dichotomy, which is pretty much Networking 201, and taken as read on NANOG. Extraordinary changes require extraordinary justification. > The objection which puzzles me the most is the implication that a > numeric address locates a host or network directly or geographically > rather than, as I understood it, by the tuple (address,route). I didn't see anyone make that implication. Could you quote? > "First they ignore you, then they ridicule you, then they fight > you, then you win" -- Mahatma Gandhi Yeah; that approach didn't work out well for Jim Fleming. :-) Seriously, Barry; my appraisal of this after three decades is that this is first year stuff, and you are not a first year guy, by any stretch. So, is this just the epic troll of the year? Or is there something we're missing? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cscora at apnic.net Fri Oct 5 18:51:50 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Oct 2012 04:51:50 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201210051851.q95IpogZ011744@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 06 Oct, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 427627 Prefixes after maximum aggregation: 178902 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 210176 Total ASes present in the Internet Routing Table: 42285 Prefixes per ASN: 10.11 Origin-only ASes present in the Internet Routing Table: 33697 Origin ASes announcing only one prefix: 15772 Transit ASes present in the Internet Routing Table: 5625 Transit-only ASes present in the Internet Routing Table: 145 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 789 Unregistered ASNs in the Routing Table: 291 Number of 32-bit ASNs allocated by the RIRs: 3352 Number of 32-bit ASNs visible in the Routing Table: 2963 Prefixes from 32-bit ASNs in the Routing Table: 8030 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space: 150 Number of addresses announced to Internet: 2604413548 Equivalent to 155 /8s, 60 /16s and 50 /24s Percentage of available address space announced: 70.3 Percentage of allocated address space announced: 70.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.7 Total number of prefixes smaller than registry allocations: 149866 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102911 Total APNIC prefixes after maximum aggregation: 32526 APNIC Deaggregation factor: 3.16 Prefixes being announced from the APNIC address blocks: 103613 Unique aggregates announced from the APNIC address blocks: 42879 APNIC Region origin ASes present in the Internet Routing Table: 4770 APNIC Prefixes per ASN: 21.72 APNIC Region origin ASes announcing only one prefix: 1242 APNIC Region transit ASes present in the Internet Routing Table: 777 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 323 Number of APNIC addresses announced to Internet: 710790048 Equivalent to 42 /8s, 93 /16s and 203 /24s Percentage of available APNIC address space announced: 83.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, 131072-133119 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: 154470 Total ARIN prefixes after maximum aggregation: 78240 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 155372 Unique aggregates announced from the ARIN address blocks: 69352 ARIN Region origin ASes present in the Internet Routing Table: 15256 ARIN Prefixes per ASN: 10.18 ARIN Region origin ASes announcing only one prefix: 5767 ARIN Region transit ASes present in the Internet Routing Table: 1596 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1086601856 Equivalent to 64 /8s, 196 /16s and 58 /24s Percentage of available ARIN address space announced: 57.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 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: 108678 Total RIPE prefixes after maximum aggregation: 57231 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 111305 Unique aggregates announced from the RIPE address blocks: 71705 RIPE Region origin ASes present in the Internet Routing Table: 16893 RIPE Prefixes per ASN: 6.59 RIPE Region origin ASes announcing only one prefix: 8136 RIPE Region transit ASes present in the Internet Routing Table: 2722 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1925 Number of RIPE addresses announced to Internet: 647652644 Equivalent to 38 /8s, 154 /16s and 101 /24s Percentage of available RIPE address space announced: 94.2 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, 196608-199679 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: 43672 Total LACNIC prefixes after maximum aggregation: 8610 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 46973 Unique aggregates announced from the LACNIC address blocks: 22575 LACNIC Region origin ASes present in the Internet Routing Table: 1661 LACNIC Prefixes per ASN: 28.28 LACNIC Region origin ASes announcing only one prefix: 453 LACNIC Region transit ASes present in the Internet Routing Table: 317 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 692 Number of LACNIC addresses announced to Internet: 117172520 Equivalent to 6 /8s, 251 /16s and 233 /24s Percentage of available LACNIC address space announced: 69.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9742 Total AfriNIC prefixes after maximum aggregation: 2237 AfriNIC Deaggregation factor: 4.35 Prefixes being announced from the AfriNIC address blocks: 10214 Unique aggregates announced from the AfriNIC address blocks: 3532 AfriNIC Region origin ASes present in the Internet Routing Table: 563 AfriNIC Prefixes per ASN: 18.14 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 126 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41908992 Equivalent to 2 /8s, 127 /16s and 123 /24s Percentage of available AfriNIC address space announced: 41.6 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 2972 11428 904 Korea Telecom (KIX) 17974 2362 830 54 PT TELEKOMUNIKASI INDONESIA 7545 1764 301 86 TPG Internet Pty Ltd 4755 1626 387 163 TATA Communications formerly 9829 1396 1154 41 BSNL National Internet Backbo 9583 1223 90 517 Sify Limited 4808 1122 2046 317 CNCGROUP IP network: China169 7552 1064 1062 11 Vietel Corporation 24560 1034 385 162 Bharti Airtel Ltd., Telemedia 9498 1018 310 74 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 3234 3728 174 bellsouth.net, inc. 7029 3166 990 161 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1924 678 128 PaeTec Communications, Inc. 22773 1903 2931 128 Cox Communications, Inc. 20115 1656 1582 618 Charter Communications 4323 1577 1154 387 Time Warner Telecom 30036 1349 270 757 Mediacom Communications Corp 7018 1267 10304 842 AT&T WorldNet Services 7011 1205 329 699 Citizens Utilities 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 8402 1734 544 16 Corbina telecom 2118 1399 97 14 EUnet/RELCOM Autonomous Syste 12479 847 776 68 Uni2 Autonomous System 34984 793 206 180 BILISIM TELEKOM 31148 722 37 9 FreeNet ISP 6830 721 2313 445 UPC Distribution Services 20940 700 222 532 Akamai Technologies European 13188 698 92 147 Educational Network 58113 631 70 366 LIR DATACENTER TELECOM SRL 8551 576 364 61 Bezeq International 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 2200 379 222 TVCABLE BOGOTA 28573 2122 1269 58 NET Servicos de Comunicao S.A 8151 1594 3047 354 UniNet S.A. de C.V. 7303 1566 1035 202 Telecom Argentina Stet-France 6503 1538 435 69 AVANTEL, S.A. 27947 724 74 91 Telconet S.A 3816 643 309 70 Empresa Nacional de Telecomun 11172 594 101 67 Servicios Alestra S.A de C.V 14420 589 87 101 CORPORACION NACIONAL DE TELEC 22047 580 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 891 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 714 958 13 TEDATA 6713 517 650 19 Itissalat Al-MAGHRIB 24835 269 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 192 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 172 682 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3234 3728 174 bellsouth.net, inc. 7029 3166 990 161 Windstream Communications Inc 4766 2972 11428 904 Korea Telecom (KIX) 17974 2362 830 54 PT TELEKOMUNIKASI INDONESIA 10620 2200 379 222 TVCABLE BOGOTA 28573 2122 1269 58 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1924 678 128 PaeTec Communications, Inc. 22773 1903 2931 128 Cox Communications, Inc. 7545 1764 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3166 3005 Windstream Communications Inc 17974 2362 2308 PT TELEKOMUNIKASI INDONESIA 4766 2972 2068 Korea Telecom (KIX) 28573 2122 2064 NET Servicos de Comunicao S.A 10620 2200 1978 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 1785 1924 1796 PaeTec Communications, Inc. 22773 1903 1775 Cox Communications, Inc. 8402 1734 1718 Corbina telecom 7545 1764 1678 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev 128.0.170.0/24 24685 ISP Elencom autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:87 /12:241 /13:477 /14:846 /15:1541 /16:12439 /17:6488 /18:10864 /19:21105 /20:30363 /21:32352 /22:42772 /23:40053 /24:223715 /25:1354 /26:1670 /27:912 /28:181 /29:65 /30:17 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2649 3166 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1802 3234 bellsouth.net, inc. 8402 1448 1734 Corbina telecom 30036 1281 1349 Mediacom Communications Corp 22773 1244 1903 Cox Communications, Inc. 11492 1164 1201 Cable One 6503 1054 1538 AVANTEL, S.A. 1785 1016 1924 PaeTec Communications, Inc. 7011 944 1205 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:627 2:711 3:1 4:13 5:553 6:3 8:467 12:1975 13:1 14:670 15:11 16:3 17:6 20:27 23:201 24:1784 27:1367 31:1022 32:54 33:2 34:2 36:7 37:838 38:829 39:2 40:133 41:2928 42:158 44:3 46:1612 47:2 49:459 50:593 52:12 54:22 55:8 56:3 57:27 58:988 59:542 60:238 61:1288 62:939 63:1997 64:4282 65:2234 66:4512 67:2107 68:1170 69:3222 70:986 71:514 72:1875 74:2600 75:484 76:305 77:967 78:977 79:469 80:1242 81:968 82:635 83:537 84:520 85:1159 86:486 87:929 88:364 89:1801 90:303 91:5235 92:593 93:1520 94:1623 95:1098 96:395 97:325 98:963 99:39 100:24 101:264 103:1631 105:512 106:120 107:199 108:466 109:1559 110:803 111:956 112:445 113:711 114:622 115:893 116:888 117:733 118:956 119:1226 120:341 121:688 122:1635 123:1165 124:1332 125:1281 128:562 129:192 130:282 131:635 132:303 133:22 134:251 135:62 136:220 137:239 138:338 139:171 140:498 141:282 142:490 143:385 144:490 145:85 146:518 147:276 148:748 149:326 150:160 151:195 152:451 153:178 154:20 155:422 156:225 157:374 158:258 159:660 160:345 161:410 162:366 163:191 164:698 165:425 166:526 167:554 168:987 169:127 170:911 171:149 172:7 173:1676 174:621 175:446 176:777 177:1258 178:1613 180:1344 181:149 182:1062 183:297 184:608 185:23 186:2187 187:1286 188:1718 189:1589 190:5805 192:6036 193:5729 194:4614 195:3660 196:1229 197:228 198:3829 199:5054 200:6002 201:1962 202:8658 203:8719 204:4400 205:2532 206:2766 207:2834 208:4045 209:3638 210:2848 211:1530 212:2013 213:1812 214:881 215:87 216:5125 217:1573 218:572 219:313 220:1250 221:534 222:337 223:415 End of report From cidr-report at potaroo.net Fri Oct 5 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Oct 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201210052200.q95M00xs012324@wattle.apnic.net> This report has been generated at Fri Oct 5 21:13:06 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-09-12 429749 247874 29-09-12 429958 247623 30-09-12 429216 247986 01-10-12 430035 248087 02-10-12 430234 248325 03-10-12 430565 247715 04-10-12 430285 248175 05-10-12 429926 248696 AS Summary 42380 Number of ASes in routing system 17639 Number of ASes announcing only one prefix 3230 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113836256 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 05Oct12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 430282 248659 181623 42.2% All ASes AS6389 3230 175 3055 94.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2125 59 2066 97.2% NET Servicos de Comunicao S.A. AS4766 2977 943 2034 68.3% KIXS-AS-KR Korea Telecom AS17974 2362 616 1746 73.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3164 1479 1685 53.3% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1903 292 1611 84.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2200 814 1386 63.0% Telmex Colombia S.A. AS2118 1399 97 1302 93.1% RELCOM-AS OOO "NPO Relcom" AS4323 1581 393 1188 75.1% TWTC - tw telecom holdings, inc. AS7303 1566 452 1114 71.1% Telecom Argentina S.A. AS1785 1927 826 1101 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1626 553 1073 66.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1120 168 952 85.0% VIETEL-AS-AP Vietel Corporation AS8151 1600 707 893 55.8% Uninet S.A. de C.V. AS18101 1014 172 842 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1122 350 772 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 859 120 739 86.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 695 54 641 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1104 477 627 56.8% LEVEL3 Level 3 Communications AS17676 713 88 625 87.7% GIGAINFRA Softbank BB Corp. AS36998 772 148 624 80.8% SDN-MOBITEL AS7545 1765 1153 612 34.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS22561 1038 428 610 58.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1033 435 598 57.9% GBLX Global Crossing Ltd. AS19262 1000 409 591 59.1% VZGNI-TRANSIT - Verizon Online LLC AS24560 1034 444 590 57.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4780 843 269 574 68.1% SEEDNET Digital United Inc. AS4804 652 97 555 85.1% MPX-AS Microplex PTY LTD AS22047 580 34 546 94.1% VTR BANDA ANCHA S.A. Total 45088 12675 32413 71.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.120.16.0/21 AS19891 BML-AS Bill Me Later, Inc 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS52390 Administradora de Redes, S.A. 200.75.185.0/24 AS52390 Administradora de Redes, S.A. 200.75.186.0/23 AS52390 Administradora de Redes, S.A. 200.75.188.0/22 AS52390 Administradora de Redes, S.A. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 5 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Oct 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201210052200.q95M01Lx012337@wattle.apnic.net> BGP Update Report Interval: 27-Sep-12 -to- 04-Oct-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS1637 58514 3.0% 657.5 -- DNIC-AS-01637 - Headquarters, USAISC 2 - AS8402 57281 3.0% 28.3 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 27171 1.4% 28.2 -- BSNL-NIB National Internet Backbone 4 - AS24560 22691 1.2% 23.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - AS22561 22378 1.2% 230.7 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - AS7552 19317 1.0% 16.0 -- VIETEL-AS-AP Vietel Corporation 7 - AS6147 19230 1.0% 59.2 -- Telefonica del Peru S.A.A. 8 - AS13118 18110 0.9% 6036.7 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS7029 15311 0.8% 5.5 -- WINDSTREAM - Windstream Communications Inc 10 - AS24186 14455 0.8% 237.0 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi 11 - AS25620 14258 0.7% 63.1 -- COTAS LTDA. 12 - AS9583 14170 0.7% 13.5 -- SIFY-AS-IN Sify Limited 13 - AS5800 11898 0.6% 46.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS26827 11349 0.6% 597.3 -- EPBTELECOM - EPB Telecom 15 - AS6629 10829 0.6% 171.9 -- NOAA-AS - NOAA 16 - AS10620 10544 0.6% 7.1 -- Telmex Colombia S.A. 17 - AS27947 10458 0.5% 23.7 -- Telconet S.A 18 - AS21599 10375 0.5% 138.3 -- NETDIRECT S.A. 19 - AS2697 10258 0.5% 101.6 -- ERX-ERNET-AS Education and Research Network 20 - AS38547 9897 0.5% 22.8 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2033 9759 0.5% 9759.0 -- PANIX - Panix Network Information Center 2 - AS13118 18110 0.9% 6036.7 -- ASN-YARTELECOM OJSC Rostelecom 3 - AS29564 3127 0.2% 3127.0 -- ASN-ITALDATA Italdata S.p.A 4 - AS14680 6669 0.3% 2223.0 -- REALE-6 - Auction.com 5 - AS6197 1308 0.1% 1308.0 -- BATI-ATL - BellSouth Network Solutions, Inc 6 - AS27977 1301 0.1% 1301.0 -- IBM Argentina S.A. 7 - AS9916 2384 0.1% 1192.0 -- NCTU-TW National Chiao Tung University, 8 - AS40009 2098 0.1% 1049.0 -- BITGRAVITY - BitGravity, Inc. 9 - AS55410 3553 0.2% 888.2 -- VODAFONE-NET-AS-AP C48 Okhla Industrial Estate, New Delhi-110020 10 - AS38857 820 0.0% 820.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 11 - AS2533 2322 0.1% 774.0 -- HOU-METRO-AS - MIS Group 12 - AS29888 1410 0.1% 705.0 -- UNUMPROVIDENT-AS - Unum Group 13 - AS26520 704 0.0% 704.0 -- NATIONAL-PRINT-GROUP-INC - National Print Group, Inc. 14 - AS27601 704 0.0% 704.0 -- NETALLIANT-TECHNOLOGIES - NetAlliant Technologies, LLC 15 - AS30397 704 0.0% 704.0 -- CHOICEDATA - CHOICEDATA 16 - AS47033 1400 0.1% 700.0 -- BASENINE-RIVERSIDE - BaseNine, Inc. 17 - AS48110 694 0.0% 694.0 -- HARKNET Harknet LLC 18 - AS39915 5479 0.3% 684.9 -- PREM-AS Premiere Global Services 19 - AS54412 2632 0.1% 658.0 -- GRANITE-1 - Granite Networks Inc. 20 - AS1637 58514 3.0% 657.5 -- DNIC-AS-01637 - Headquarters, USAISC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 18099 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.157.224.0/19 11057 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 184.159.130.0/23 10797 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - 182.64.0.0/16 10297 0.5% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 200.46.0.0/19 10184 0.5% AS21599 -- NETDIRECT S.A. 6 - 122.161.0.0/16 10017 0.5% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 209.48.168.0/24 9759 0.5% AS2033 -- PANIX - Panix Network Information Center 8 - 5.102.192.0/19 8383 0.4% AS47956 -- XFONE XFONE COMMUNICATION LTD 9 - 202.41.70.0/24 7711 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 10 - 190.60.31.0/24 7002 0.3% AS18747 -- IFX-NW - IFX Communication Ventures, Inc. 11 - 77.235.147.0/24 5817 0.3% AS16130 -- FiberLink Networks 12 - 95.128.195.0/24 5418 0.3% AS39915 -- PREM-AS Premiere Global Services 13 - 12.139.133.0/24 5365 0.3% AS14680 -- REALE-6 - Auction.com 14 - 192.58.232.0/24 5321 0.3% AS6629 -- NOAA-AS - NOAA 15 - 192.58.2.0/24 5223 0.2% AS6629 -- NOAA-AS - NOAA 16 - 194.63.9.0/24 5017 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 17 - 49.248.72.0/21 4447 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 18 - 69.38.178.0/24 4106 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 19 - 123.252.208.0/24 3279 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 20 - 213.92.117.0/24 3127 0.1% AS29564 -- ASN-ITALDATA Italdata S.p.A 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 tkapela at gmail.com Fri Oct 5 22:31:58 2012 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 5 Oct 2012 17:31:58 -0500 Subject: max-prefix and platform tcam limits: they are things Message-ID: Submitted without comment: http://inside.godaddy.com/inside-story-happened-godaddy-com-sept-10-2012/ -Tk From bzs at world.std.com Fri Oct 5 23:34:14 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 5 Oct 2012 19:34:14 -0400 Subject: IPv4 address length technical design In-Reply-To: <20121005164751.50925.qmail@joyce.lan> References: <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40@W8USSFJ204.ams.gblxint.com> <20121005164751.50925.qmail@joyce.lan> Message-ID: <20591.28278.961557.174820@world.std.com> Well, XNS (Xerox Networking System from PARC) used basically MAC addresses. Less a demonstration of success than that it has been tried. But it's where ethernet MAC addresses come from, they're just XNS addresses and maybe this has changed but Xerox used to manage the master 802 OUI list and are assigned OUIs 000000...000009. Not insignificant in their effect. There have been various schemes for UUIDs, intended to be unique, for both hosts and disks or file systems, some quite widely deployed IBM's System-36 in the early 80s but also Linux extN, others, see RFC 4122. On October 5, 2012 at 16:47 johnl at iecc.com (John Levine) wrote: > In article <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40 at W8USSFJ204.ams.gblxint.com> you write: > >Wouldn't that implicate the routing system to have, in essence, one routing entry for every host on the network? > > > >That would be the moral equivalent to just dropping down to a global ethernet fabric to replace IP and using mac addresses for > >routing. I'll give you one guess as to how well that would work. > > It works well for the 12 computers in my home office. Therefore it's > a solved problem and trivial to implement. > > HTH, HAND, &c. > John -- -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 deleskie at gmail.com Sat Oct 6 00:05:07 2012 From: deleskie at gmail.com (jim deleskie) Date: Fri, 5 Oct 2012 21:05:07 -0300 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: References: Message-ID: I know that I should know better then comment on networks others then my own, ( and I know to never comment on my own publicly :) ) But here goes, 210x the size of normal really? 210% I'd have a hard time believing. Did anyone else anywhere see a route leak equal to larger then the entire Internet that day, anywhere else that could of caused this? I won't even get into max-prefix and how we've managed this long with someone people still not setting them. -jim On Fri, Oct 5, 2012 at 7:31 PM, Anton Kapela wrote: > Submitted without comment: > http://inside.godaddy.com/inside-story-happened-godaddy-com-sept-10-2012/ > > -Tk > From Valdis.Kletnieks at vt.edu Sat Oct 6 00:17:44 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 Oct 2012 20:17:44 -0400 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: Your message of "Fri, 05 Oct 2012 21:05:07 -0300." References: Message-ID: <13847.1349482664@turing-police.cc.vt.edu> On Fri, 05 Oct 2012 21:05:07 -0300, jim deleskie said: > But here goes, 210x the size of normal really? 210% I'd have a hard > time believing. Did anyone else anywhere see a route leak equal to > larger then the entire Internet that day, anywhere else that could of > caused this? If the device was only expecting 2K or so internal routes, getting hit with the 440K routes in the DFZ would be 210x.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From deleskie at gmail.com Sat Oct 6 00:21:27 2012 From: deleskie at gmail.com (jim deleskie) Date: Fri, 5 Oct 2012 21:21:27 -0300 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: <13847.1349482664@turing-police.cc.vt.edu> References: <13847.1349482664@turing-police.cc.vt.edu> Message-ID: Yes that math would work, but if your device can't handle 1x Internet routing and your running without some serious max-prefix/filters it says even more about your IP eng team then I'd be willing to comment on. -jim On Fri, Oct 5, 2012 at 9:17 PM, wrote: > On Fri, 05 Oct 2012 21:05:07 -0300, jim deleskie said: > >> But here goes, 210x the size of normal really? 210% I'd have a hard >> time believing. Did anyone else anywhere see a route leak equal to >> larger then the entire Internet that day, anywhere else that could of >> caused this? > > If the device was only expecting 2K or so internal routes, getting hit with > the 440K routes in the DFZ would be 210x.... From jlewis at lewis.org Sat Oct 6 00:25:57 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 5 Oct 2012 20:25:57 -0400 (EDT) Subject: max-prefix and platform tcam limits: they are things In-Reply-To: References: Message-ID: On Fri, 5 Oct 2012, jim deleskie wrote: > I know that I should know better then comment on networks others then > my own, ( and I know to never comment on my own publicly :) ) > > > But here goes, 210x the size of normal really? 210% I'd have a hard > time believing. Did anyone else anywhere see a route leak equal to > larger then the entire Internet that day, anywhere else that could of > caused this? Is it plausible that Godaddy's internal network only normally has a few thousand BGP routes? 210 x a few thousand would run most modern gear out of FIB space. The "my DNS is broken, are we really being DDoS'd on udp/53 at the same time?" thing, I've seen, and I can imagine it being very confusing to someone seeing it for the first time. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bzs at world.std.com Sat Oct 6 00:25:19 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 5 Oct 2012 20:25:19 -0400 Subject: IPv4 address length technical design Message-ID: <20591.31343.30301.633043@world.std.com> > While this is an interesting thought experiment, what problem are > you trying to solve with this proposal? (asked privately but it seems worthwhile answering publicly, bcc'd, you can id yourself if you like.) Look, as I said in the original message I was asked to speak to a group of young "hackers" at the HackerSpace in Singapore. I wanted to be interesting and thought-provoking, make them think through how this stuff works for an hour or two, encourage them to poke holes in it, etc. It was one of the audience who pointed out the potential MTU problem. What problem does it solve, potentially? 0. Despite fears expressed herein I am not single-handedly planning to convert the worldwide internet to this over the weekend. I'm going to need some help :-) 1. It eliminates the need for DNS in its generally used form. Sure, we've overloaded DNS with other functions from SPF -- in fact it was Meng Weng Wong, inventor of SPF, who graciously invited me to speak -- to whatever. But that's begging the point, there's nothing interesting here about distributed, lightweight databases other than eliminating one. Keep the DNS protocol per se for those things if you like. But given this you won't need to translate between host names and addresses which is really what DNS was invented to do. 2. It makes "addresses" more transparent to humans, particularly when you consider ipv6 addresses as typically displayed (hex.) Is this an important goal? Not sure, but it's certainly true. 3. It's a transfinite space. That just means that like Dewey Decimal etc it can be arbitrarily expanded, you can add more levels or even stick levels in between plus or minus some rules regarding SLDs/TLDs, and other rules which might or might not be imposed (see #4). But its total address space is as large as you allow a payload, there is nothing inherent in the scheme that limits the addressing other than the permutation of all acceptable Unicode glyphs I guess. But since one can also have numeric parts and the set of integers is infinite (that's tongue-in-cheek, somewhat.) 4. Also, because it's transfinite it's arbitrarily segmentable. Again, that just means you can impose any meaning you like on any substring or set of substrings. So for example host.gTLD is generally taken to be something of some significance, or host.co.ccTLD, and that sort of idea can be applied as needed, or not at all. 5. Bits is bits. I don't know how to say that more clearly. An ipv6 address is a string of 128 bits with some segmentation implications (net part, host part.) A host name is a string of bits of varying length. But it's still just ones and zeros, an integer, however you want to read it. The discussion I was responding to on NANOG involved how we got here and where might we be going. I brought up an idea I'd worked out somewhat and have even presented in a small but public forum as being a possible future to consider further. Now you can go back to your regularly scheduled Jim Fleming guffawing. -- -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 joelja at bogus.com Sat Oct 6 00:36:30 2012 From: joelja at bogus.com (joel jaeggli) Date: Fri, 05 Oct 2012 17:36:30 -0700 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: References: Message-ID: <506F7D0E.8040709@bogus.com> On 10/5/12 5:05 PM, jim deleskie wrote: > I know that I should know better then comment on networks others then > my own, ( and I know to never comment on my own publicly :) ) > > > But here goes, 210x the size of normal really? 210% I'd have a hard > time believing. Did anyone else anywhere see a route leak equal to > larger then the entire Internet that day, anywhere else that could of > caused this? it's pretty easy to inadvertently leak a copy of the internet from one vrf to another and effectively install two copies of the internet routes in your fib... There are plently of cases where you might to that or something similar on purpose, which is all good and well if you have 2million route fib capacity but less awesome if you have 512K route capacity linecards at this point. if you get those routes from a private peer on some non-internet-vrf well that might imply that your filter policy needs some tuning. > I won't even get into max-prefix and how we've managed this long with > someone people still not setting them. > > > -jim > On Fri, Oct 5, 2012 at 7:31 PM, Anton Kapela wrote: >> Submitted without comment: >> http://inside.godaddy.com/inside-story-happened-godaddy-com-sept-10-2012/ >> >> -Tk >> From dmiller at tiggee.com Sat Oct 6 00:38:30 2012 From: dmiller at tiggee.com (David Miller) Date: Fri, 05 Oct 2012 20:38:30 -0400 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: <13847.1349482664@turing-police.cc.vt.edu> References: <13847.1349482664@turing-police.cc.vt.edu> Message-ID: <506F7D86.3010005@tiggee.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/5/2012 8:17 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 05 Oct 2012 21:05:07 -0300, jim deleskie said: > >> But here goes, 210x the size of normal really? 210% I'd have a >> hard time believing. Did anyone else anywhere see a route leak >> equal to larger then the entire Internet that day, anywhere else >> that could of caused this? > > If the device was only expecting 2K or so internal routes, getting > hit with the 440K routes in the DFZ would be 210x.... > On outages GoDaddy provided a tiny bit more information. [quote] Obviously the explanation of the incident had to be consumed by the general public, however we encountered an unknown bug that was found which started the domino effect. Aside from this group, that level of detail wouldn't be understood by a majority of the recipients. With that said, please feel free to take this off list with Jason or Myself. Mike Dob Manager, Network Engineering [/quote] No information has been provided on what sort of "unknown bug" this was. A bug in code that GoDaddy wrote? A bug in their route servers or router OS, which others may also use and might want to be aware of? - -DMM -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQb32GAAoJECp6zT7OFmGa5wYIAIWp9vUwS/5zM73cAXlUrpwR 5U3XuUn3fasq8JyuNFhe99aDhkQY+i5tQEFhhhB60dVfWcyVGYsO1Ny0FMXupYfE Ely29vxutWHMDxX39XTvmmtNkeSsZ2cOtkqF14If+43/CccrDwDDiC06YoSyxb/x JEjWMhcthcw8rbndzF3P+bRCerdyxPpeQLzNy+l0/SbjobsLwzDA28CPW2kL82Bh 67dgqdXiMVFARC8rc91bYAoJ+NtkLs/GwYSbgXdNCk5dGrZvOk1rVWzaKxBrNV8T rldU43GRzeq2bJAKo0fx17/HE4j9qlfeBIW+bihwgkMpzw8p3kRS9S0WU4cGxGM= =1nls -----END PGP SIGNATURE----- From fred at cisco.com Sat Oct 6 01:06:06 2012 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 6 Oct 2012 01:06:06 +0000 Subject: IPv4 address length technical design In-Reply-To: <20591.28278.961557.174820@world.std.com> References: <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40@W8USSFJ204.ams.gblxint.com> <20121005164751.50925.qmail@joyce.lan> <20591.28278.961557.174820@world.std.com> Message-ID: <8C48B86A895913448548E6D15DA7553B162F7B@xmb-rcd-x09.cisco.com> On Oct 5, 2012, at 4:34 PM, Barry Shein wrote: > Well, XNS (Xerox Networking System from PARC) used basically MAC > addresses. Less a demonstration of success than that it has been > tried. But it's where ethernet MAC addresses come from, they're just > XNS addresses and maybe this has changed but Xerox used to manage the > master 802 OUI list and are assigned OUIs 000000...000009. Not > insignificant in their effect. You need a memory refresh. XNS used a three part address: network number, host identifier, and socket number. "Socket" was in essence the TCP/UDP Port Number. the host identifier was as you say a 48 bit number and generally took as its value the MAC address on one of the interfaces - and the same MAC address was used on all interfaces. Hence, no need for ARP/ND. The network number was a 32 bit number assigned to a LAN subnet. A multihomed host essentially implemented ILNP. The issue with the network number was, of course, that it couldn't be aggregated in any useful way. But XNS was not ethernet bridging on a wide scale. From lane.powers at swat.coop Sat Oct 6 01:08:52 2012 From: lane.powers at swat.coop (Lane Powers) Date: Fri, 5 Oct 2012 20:08:52 -0500 Subject: max-prefix and platform tcam limits: they are things In-Reply-To: References: Message-ID: In case you missed it On Oct 5, 2012, at 7:05 PM, jim deleskie wrote: > I know that I should know better then comment on networks others then > my own, ( and I know to never comment on my own publicly :) ) > > > But here goes, 210x the size of normal really? 210% I'd have a hard > time believing. Did anyone else anywhere see a route leak equal to > larger then the entire Internet that day, anywhere else that could of > caused this? > > I won't even get into max-prefix and how we've managed this long with > someone people still not setting them. > > > -jim > On Fri, Oct 5, 2012 at 7:31 PM, Anton Kapela wrote: >> Submitted without comment: >> http://inside.godaddy.com/inside-story-happened-godaddy-com-sept-10-2012/ >> >> -Tk > > From mike at mtcc.com Sat Oct 6 01:11:14 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 05 Oct 2012 18:11:14 -0700 Subject: IPv4 address length technical design In-Reply-To: <20591.31343.30301.633043@world.std.com> References: <20591.31343.30301.633043@world.std.com> Message-ID: <506F8532.4050803@mtcc.com> On 10/05/2012 05:25 PM, Barry Shein wrote: > 5. Bits is bits. > > I don't know how to say that more clearly. > > An ipv6 address is a string of 128 bits with some segmentation > implications (net part, host part.) > > A host name is a string of bits of varying length. But it's still just > ones and zeros, an integer, however you want to read it. Wasn't David Cheriton proposing something like this? http://www-dsg.stanford.edu/triad/ Mike From bill at herrin.us Sat Oct 6 01:47:42 2012 From: bill at herrin.us (William Herrin) Date: Fri, 5 Oct 2012 21:47:42 -0400 Subject: IPv4 address length technical design In-Reply-To: <20591.31343.30301.633043@world.std.com> References: <20591.31343.30301.633043@world.std.com> Message-ID: On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein wrote: > 5. Bits is bits. > I don't know how to say that more clearly. Hi Barry, Bits is bits and atoms is atoms so lets swap all the iron for helium and see how that works out for us. You can say "bits as bits" as clearly as you like but however you say it you'll be wrong. Bits are defined by the semantics of their use. Any equality or inequality between one bit and another, and in fact whether they can be meaningfully compared at all, is found in those semantics. Bits ain't just bits. Bits are information *in context.* Change the context, change the bits. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dmiller at tiggee.com Sat Oct 6 01:55:41 2012 From: dmiller at tiggee.com (David Miller) Date: Fri, 05 Oct 2012 21:55:41 -0400 Subject: IPv4 address length technical design In-Reply-To: <506F8532.4050803@mtcc.com> References: <20591.31343.30301.633043@world.std.com> <506F8532.4050803@mtcc.com> Message-ID: <506F8F9D.2030705@tiggee.com> On 10/5/2012 9:11 PM, Michael Thomas wrote: > On 10/05/2012 05:25 PM, Barry Shein wrote: >> 5. Bits is bits. >> >> I don't know how to say that more clearly. >> >> An ipv6 address is a string of 128 bits with some segmentation >> implications (net part, host part.) >> >> A host name is a string of bits of varying length. But it's still just >> ones and zeros, an integer, however you want to read it. > > Wasn't David Cheriton proposing something like this? > > http://www-dsg.stanford.edu/triad/ > > Mike Not exactly. TRIAD is a proposal for distributing content names using a new routing protocol (in addition to existing routing protocols instead of as a replacement for existing routing protocols) such that one could "Route a content request, based on its name, toward the closest server for that name."(1) The actual forwarding of packets/requests would continue to use IP. TRIAD addresses issues with namespace size using Explicit Aggregation into collections. (2) -DMM 1. http://www-dsg.stanford.edu/slides/triad-content-netseminar/img15.htm 2. http://gregorio.stanford.edu/papers/contentrouting/node9.html#SECTION00041000000000000000 From jra at baylink.com Sat Oct 6 02:20:48 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Oct 2012 22:20:48 -0400 (EDT) Subject: ESR muses on, among other things, the early IETF Message-ID: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> Those who know Fred and knew Jon personally might want to throw an oar in the water on this blog posting from last month... http://esr.ibiblio.org/?p=4591 And that's not mentioning, of course, the people who want to throw the oar *at* ESR: I know he's a polarizing individual. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From tvhawaii at shaka.com Sat Oct 6 02:48:49 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 5 Oct 2012 16:48:49 -1000 Subject: ESR muses on, among other things, the early IETF References: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> Message-ID: <55B17B14575B4B5DAD596EF2B4BAFDC2@owner59e1f1502> Jay Ashworth wrote: > Those who know Fred and knew Jon personally might want to throw an oar in the > water on this blog posting from last month... > > http://esr.ibiblio.org/?p=4591 > > And that's not mentioning, of course, the people who want to throw the oar > *at* ESR: I know he's a polarizing individual. :-) > > Cheers, > -- jra Ahh hell...it's Friday. http://www.theatlantic.com/international/archive/2012/10/hacktivists-advocate-meet-the-lawyer-who-defends-anonymous/263202/# From nick at foobar.org Sat Oct 6 09:14:41 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 06 Oct 2012 10:14:41 +0100 Subject: ESR muses on, among other things, the early IETF In-Reply-To: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> References: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> Message-ID: <506FF681.1050300@foobar.org> On 06/10/2012 03:20, Jay Ashworth wrote: > Those who know Fred and knew Jon personally might want to throw an oar in the > water on this blog posting from last month... > > http://esr.ibiblio.org/?p=4591 not sure if it's appropriate to associate some of the prime movers of the Internet with a cringingly self-aggrandising blog posting like that. Nick From bmanning at vacation.karoshi.com Sat Oct 6 10:39:29 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 6 Oct 2012 10:39:29 +0000 Subject: ESR muses on, among other things, the early IETF In-Reply-To: <506FF681.1050300@foobar.org> References: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> <506FF681.1050300@foobar.org> Message-ID: <20121006103929.GA29606@vacation.karoshi.com.> On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote: > On 06/10/2012 03:20, Jay Ashworth wrote: > > Those who know Fred and knew Jon personally might want to throw an oar in the > > water on this blog posting from last month... > > > > http://esr.ibiblio.org/?p=4591 > > not sure if it's appropriate to associate some of the prime movers of the > Internet with a cringingly self-aggrandising blog posting like that. > > Nick I -think- Jon and Fred were not contemporaries. Fred is closer to my age than Jon. /bill From bzs at world.std.com Sat Oct 6 16:25:09 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 6 Oct 2012 12:25:09 -0400 (EDT) Subject: news.google.com (and others)? Message-ID: <201210061625.q96GP9Oa007003@world.std.com> This has been going on for days. We couldn't get thru to news.google.com but most everything else works. Once in a while it works. Connection is through towerstream.com. Traceroute usually seems to go through, sometimes dies somewhere out there past their network (72.14...? maybe abovenet?), no consistent result. Tried downforeveryoneorjustme.com, it says it's up. Called towerstream support, they couldn't get thru either. WAIT! The support guy had a tablet on Verizon 4G, he couldn't get thru to news.google.com using that either. He also said he couldn't get thru to google street maps, but google mail was ok (I can reload gplus.google.com no problem.) My iphone via AT&T has no problem, loads news.google.com immediately. Anyone else seeing this? I'm in Boston, Towerstream support is in Providence, RI. I'm thinking some sort of localized problem but trouble thru towerstream and verizon? It was passed to the engineer on duty at towerstream who will look into it and speak to google if necessary, not clear it's their problem though, not if Verizon is actually also having the same problem. -- -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 morrowc.lists at gmail.com Sat Oct 6 16:36:30 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 6 Oct 2012 12:36:30 -0400 Subject: news.google.com (and others)? In-Reply-To: <201210061625.q96GP9Oa007003@world.std.com> References: <201210061625.q96GP9Oa007003@world.std.com> Message-ID: On Sat, Oct 6, 2012 at 12:25 PM, Barry Shein wrote: > > This has been going on for days. > > We couldn't get thru to news.google.com but most everything else > works. Once in a while it works. > > Connection is through towerstream.com. Traceroute usually seems to go > through, sometimes dies somewhere out there past their network > (72.14...? maybe abovenet?), no consistent result. 72.14.? some of that is google network space: NET-72-14-192-0-1 - for instance > Tried downforeveryoneorjustme.com, it says it's up. ;; ANSWER SECTION: www.downforeveryoneorjustme.com. 1568 IN CNAME ghs.google.com. ghs.google.com. 43199 IN CNAME ghs.l.google.com. ghs.l.google.com. 299 IN A 173.194.74.121 really: "Down for google or just me" would be a better name :( > > Called towerstream support, they couldn't get thru either. > > WAIT! > > The support guy had a tablet on Verizon 4G, he couldn't get thru to > news.google.com using that either. > > He also said he couldn't get thru to google street maps, but google > mail was ok (I can reload gplus.google.com no problem.) > > My iphone via AT&T has no problem, loads news.google.com immediately. > > Anyone else seeing this? > what sort of source address are you using? perhaps also ipv4 vs ipv6? (the lte devices will default, I believe, to v6) > I'm in Boston, Towerstream support is in Providence, RI. > > I'm thinking some sort of localized problem but trouble thru > towerstream and verizon? > > It was passed to the engineer on duty at towerstream who will look > into it and speak to google if necessary, not clear it's their problem > though, not if Verizon is actually also having the same problem. Connecting to news.google.com|2607:f8b0:4003:c02::8b|:80... connected. HTTP request sent, awaiting response... 200 OK from some network in the interwebs... so v6 to this works (v4 works as well, based on telnet responses) -chris > > -- > -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 Sat Oct 6 17:47:26 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 6 Oct 2012 13:47:26 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <20591.31343.30301.633043@world.std.com> Message-ID: <20592.28334.622769.539587@world.std.com> It's occured to you that FQDNs contain some structured information, no? -b On October 5, 2012 at 21:47 bill at herrin.us (William Herrin) wrote: > On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein wrote: > > 5. Bits is bits. > > I don't know how to say that more clearly. > > Hi Barry, > > Bits is bits and atoms is atoms so lets swap all the iron for helium > and see how that works out for us. > > You can say "bits as bits" as clearly as you like but however you say > it you'll be wrong. Bits are defined by the semantics of their use. > Any equality or inequality between one bit and another, and in fact > whether they can be meaningfully compared at all, is found in those > semantics. > > Bits ain't just bits. Bits are information *in context.* Change the > context, change the bits. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From george.herbert at gmail.com Sat Oct 6 18:06:41 2012 From: george.herbert at gmail.com (George Herbert) Date: Sat, 6 Oct 2012 11:06:41 -0700 Subject: IPv4 address length technical design In-Reply-To: <20592.28334.622769.539587@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> Message-ID: As I said earlier, names' structure does not map to network or physical location structure. DNS is who; IP is where. Both are reasonably efficient now as separate entities. Combining them will wreck one. You're choosing to wreck routing (where), which to backbone people sounds frankly stark raving mad. If you aren't willing to consider where / routing as a problem of equal importance ( not as end-user visible perhaps, but ultimately as important ), then you're just pissing around and not being serious about exploring future options. George William Herbert Sent from my iPhone On Oct 6, 2012, at 10:47 AM, Barry Shein wrote: > > It's occured to you that FQDNs contain some structured information, > no? > > -b > > On October 5, 2012 at 21:47 bill at herrin.us (William Herrin) wrote: >> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein wrote: >>> 5. Bits is bits. >>> I don't know how to say that more clearly. >> >> Hi Barry, >> >> Bits is bits and atoms is atoms so lets swap all the iron for helium >> and see how that works out for us. >> >> You can say "bits as bits" as clearly as you like but however you say >> it you'll be wrong. Bits are defined by the semantics of their use. >> Any equality or inequality between one bit and another, and in fact >> whether they can be meaningfully compared at all, is found in those >> semantics. >> >> Bits ain't just bits. Bits are information *in context.* Change the >> context, change the bits. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > From bzs at world.std.com Sat Oct 6 18:35:32 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 6 Oct 2012 14:35:32 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> Message-ID: <20592.31220.78712.550345@world.std.com> Well, George, you can take a new idea and run with it a bit, or just resist it right from the start. We can map from host names to ip addresses to routing actions, right? So clearly they're not unrelated or independent variables. There's a smooth function from hostname->ipaddr->routing. Take an extreme but extremely common case, the home or small office end user. Those packets only have exactly one place to go, right? One default route. So why do they need to turn a host name into an IP address at all to ship a packet? The first-hop route is always exactly the same for every single packet. Is this a good use of DNS computrons? Answering DNS inquiries for every new connection for every single-routed host on the internet? Van Jacobson had a similar observation vis a vis TCP and PPP header compression, why keep sending the same bits back and forth over a PPP link for example? Why not just an encapsulation which says "same as previous"? Now, how can that be generalized? -b On October 6, 2012 at 11:06 george.herbert at gmail.com (George Herbert) wrote: > As I said earlier, names' structure does not map to network or physical location structure. > > DNS is who; IP is where. Both are reasonably efficient now as separate entities. Combining them will wreck one. You're choosing to wreck routing (where), which to backbone people sounds frankly stark raving mad. > > If you aren't willing to consider where / routing as a problem of equal importance ( not as end-user visible perhaps, but ultimately as important ), then you're just pissing around and not being serious about exploring future options. > > > > George William Herbert > Sent from my iPhone > > On Oct 6, 2012, at 10:47 AM, Barry Shein wrote: > > > > > It's occured to you that FQDNs contain some structured information, > > no? > > > > -b > > > > On October 5, 2012 at 21:47 bill at herrin.us (William Herrin) wrote: > >> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein wrote: > >>> 5. Bits is bits. > >>> I don't know how to say that more clearly. > >> > >> Hi Barry, > >> > >> Bits is bits and atoms is atoms so lets swap all the iron for helium > >> and see how that works out for us. > >> > >> You can say "bits as bits" as clearly as you like but however you say > >> it you'll be wrong. Bits are defined by the semantics of their use. > >> Any equality or inequality between one bit and another, and in fact > >> whether they can be meaningfully compared at all, is found in those > >> semantics. > >> > >> Bits ain't just bits. Bits are information *in context.* Change the > >> context, change the bits. > >> > >> Regards, > >> Bill Herrin > >> > >> > >> -- > >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us > >> 3005 Crane Dr. ...................... Web: > >> Falls Church, VA 22042-3004 > > -- -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 nanog at allenwilson.com Sat Oct 6 18:59:01 2012 From: nanog at allenwilson.com (nanog at allenwilson.com) Date: Sat, 6 Oct 2012 14:59:01 -0400 Subject: IPv4 address length technical design In-Reply-To: <29525376.28501.1349460368640.JavaMail.root@benjamin.baylink.com> References: <20591.6447.608649.221847@world.std.com> <29525376.28501.1349460368640.JavaMail.root@benjamin.baylink.com> Message-ID: <00e301cda3f4$a60278e0$f2076aa0$@allenwilson.com> My money is on an epic troll. Four out of five network engineers surveyed agree their individual IP headers are best served without condiments. -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Friday, October 05, 2012 2:06 PM To: NANOG Subject: Re: IPv4 address length technical design ----- Original Message ----- > From: "Barry Shein" > Don't change anything! That would...change things! Your man; he is made of straw. :-) > Obviously my idea to use the host name directly as a src/dest address > rather than convert it to an integer is not a small, incremental > change. It's more in the realm of a speculative proposal. Speculative is orthogonal to small or incremental; they are different measurement axes. This is also true of the difference between addresses and names. Addresses are an engineering artifact; names are a business/administrative artifact. *The entire point* of DNS vs IP is to uncouple those; necessary changes in the engineering artifact *MUST not* cause changes in the business artifact. > But I'm not sure that arguing that our string of bits (e.g., ipv6) is > inherently superior to your proposed string of bits (a host name) is > an immediately compelling objection. And, unsurprisingly, no one made an argument that trivial. To the extent you think we did, I think we were merely giving you the benefit of the doubt of already understanding this dichotomy, which is pretty much Networking 201, and taken as read on NANOG. Extraordinary changes require extraordinary justification. > The objection which puzzles me the most is the implication that a > numeric address locates a host or network directly or geographically > rather than, as I understood it, by the tuple (address,route). I didn't see anyone make that implication. Could you quote? > "First they ignore you, then they ridicule you, then they fight you, > then you win" -- Mahatma Gandhi Yeah; that approach didn't work out well for Jim Fleming. :-) Seriously, Barry; my appraisal of this after three decades is that this is first year stuff, and you are not a first year guy, by any stretch. So, is this just the epic troll of the year? Or is there something we're missing? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From hank at efes.iucc.ac.il Sat Oct 6 20:02:35 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 6 Oct 2012 22:02:35 +0200 (IST) Subject: max-prefix and platform tcam limits: they are things In-Reply-To: References: <13847.1349482664@turing-police.cc.vt.edu> Message-ID: On Fri, 5 Oct 2012, jim deleskie wrote: Just ask yourself how many times you have seen a Godaddy IP/NOC person post anything to NANOG or to any other technical forum? -Hank > Yes that math would work, but if your device can't handle 1x Internet > routing and your running without some serious max-prefix/filters it > says even more about your IP eng team then I'd be willing to comment > on. > > -jim > > On Fri, Oct 5, 2012 at 9:17 PM, wrote: >> On Fri, 05 Oct 2012 21:05:07 -0300, jim deleskie said: >> >>> But here goes, 210x the size of normal really? 210% I'd have a hard >>> time believing. Did anyone else anywhere see a route leak equal to >>> larger then the entire Internet that day, anywhere else that could of >>> caused this? >> >> If the device was only expecting 2K or so internal routes, getting hit with >> the 440K routes in the DFZ would be 210x.... > From james.cutler at consultant.com Sat Oct 6 20:08:04 2012 From: james.cutler at consultant.com (Cutler James R) Date: Sat, 6 Oct 2012 16:08:04 -0400 Subject: IPv4 address length technical design In-Reply-To: <20592.31220.78712.550345@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> Message-ID: On Oct 6, 2012, at 2:35 PM, Barry Shein wrote, in part: > > We can map from host names to ip addresses to routing actions, right? > > So clearly they're not unrelated or independent variables. There's a > smooth function from hostname->ipaddr->routing. I would suggest that this is a bit optimistic and oversimplified. The mapping between DNS names and IP addresses is not necessarily unique or commutative. One may change either arbitrarily, as long some "directory service" exists which contains the current mapping. In addition, multiple DNS names may map to one or more IP addresses and IP addresses do not necessarily map to unique routes or DNS names. These are not smooth functions. If names and addresses are not independent, then any change in either would predicate a change in the another. That is apparently not the experience of most network providers. The only action required for a change in network name or address is to update the "directory service" used to map between name and address. > Is this a good use of DNS computrons? Answering DNS inquiries for > every new connection for every single-routed host on the internet? Yes, it is. Most "new" connections are repeats of previous connections (I request mail from my IMAP servers several times each day) and the preponderance of caching resolvers make the effort and traffic trivial. Even in the absence of cached final DNS reply, putting the lookup burden on the end system rather than the "routing engines" should be a no-brainer. In particular, adding caching of connection destinations within routing components would not only seriously burden (read, slow down) routing engines but is also a violation of the Stupid Network. David S Isenberg said, "In a Stupid Network, control passes from the center to the edge". See http://www.isen.com/papers/Dawnstupid.html, originally published as the cover story of ACM Networker 2.1, February/March 1998, pp. 24-31. From rbf+nanog at panix.com Sat Oct 6 20:37:24 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 6 Oct 2012 15:37:24 -0500 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> Message-ID: <20121006203724.GA26642@panix.com> On Fri, Oct 05, 2012 at 10:24:18AM -0500, Ben Bartsch wrote: > use this: > > http://www.team-cymru.org/Services/Bogons/bgp.html Please tell me how I can configure my router to use that feed to automatically reject any bogon advertisements I receive from other BGP neigbhors. > On Fri, Oct 5, 2012 at 10:18 AM, Jared Mauch wrote: > > > > I suspect not everyone has updated their 'bogon' filters. I found a very > > minor gap in our filters, we are working on correcting it. -- Brett From randy at psg.com Sat Oct 6 23:22:15 2012 From: randy at psg.com (Randy Bush) Date: Sat, 06 Oct 2012 16:22:15 -0700 Subject: 100.100.0.0/24 In-Reply-To: <20121006203724.GA26642@panix.com> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> <20121006203724.GA26642@panix.com> Message-ID: >> http://www.team-cymru.org/Services/Bogons/bgp.html > Please tell me how I can configure my router to use that feed to > automatically reject any bogon advertisements I receive from other BGP > neigbhors. you actually have to look at that web page From vasil at ludost.net Sat Oct 6 23:31:19 2012 From: vasil at ludost.net (Vasil Kolev) Date: Sun, 07 Oct 2012 02:31:19 +0300 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> <20121006203724.GA26642@panix.com> Message-ID: <1349566279.5173.4.camel@nymphadora.home.ludost.net> ? 16:22 -0700 ?? 06.10.2012 (??), Randy Bush ??????: > >> http://www.team-cymru.org/Services/Bogons/bgp.html > > Please tell me how I can configure my router to use that feed to > > automatically reject any bogon advertisements I receive from other BGP > > neigbhors. > > you actually have to look at that web page > If you're seeing the same page, the configs and explanations there show how to drop packets destined to bogons, not routes. (I also want to know the answer to that question) -- Regards, Vasil Kolev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Sat Oct 6 23:34:19 2012 From: randy at psg.com (Randy Bush) Date: Sat, 06 Oct 2012 16:34:19 -0700 Subject: 100.100.0.0/24 In-Reply-To: <1349566279.5173.4.camel@nymphadora.home.ludost.net> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> <20121006203724.GA26642@panix.com> <1349566279.5173.4.camel@nymphadora.home.ludost.net> Message-ID: >>>> http://www.team-cymru.org/Services/Bogons/bgp.html >>> Please tell me how I can configure my router to use that feed to >>> automatically reject any bogon advertisements I receive from other BGP >>> neigbhors. >> >> you actually have to look at that web page > > If you're seeing the same page, the configs and explanations there show > how to drop packets destined to bogons, not routes. > > (I also want to know the answer to that question) then read the frelling page!!! http://www.team-cymru.org/Services/Bogons/bgp-examples.html#cisco-full-v4trans router bgp ! Session 1 neighbor A.B.C.D remote-as 65332 neighbor A.B.C.D description neighbor A.B.C.D ebgp-multihop 255 neighbor A.B.C.D password ! Session 2 neighbor E.F.G.H remote-as 65332 neighbor E.F.G.H description neighbor E.F.G.H ebgp-multihop 255 neighbor E.F.G.H password ! address-family ipv4 ! Session 1 neighbor A.B.C.D activate neighbor A.B.C.D soft-reconfiguration inbound neighbor A.B.C.D prefix-list cymru-out-v4 out neighbor A.B.C.D route-map CYMRUBOGONS-V4 in ! Session 2 neighbor E.F.G.H activate neighbor E.F.G.H soft-reconfiguration inbound neighbor E.F.G.H prefix-list cymru-out-v4 out neighbor E.F.G.H route-map CYMRUBOGONS-V4 in ! address-family ipv6 ! Session 1 neighbor A.B.C.D activate neighbor A.B.C.D soft-reconfiguration inbound neighbor A.B.C.D prefix-list cymru-out-v6 out neighbor A.B.C.D route-map CYMRUBOGONS-V6 in ! Session 2 neighbor E.F.G.H activate neighbor E.F.G.H soft-reconfiguration inbound neighbor E.F.G.H prefix-list cymru-out-v6 out neighbor E.F.G.H route-map CYMRUBOGONS-V6 in ! ! Depending on IOS version, you may need to configure your router ! for new-style community syntax. ip bgp-community new-format ! ip community-list 100 permit 65332:888 ! ip route 192.0.2.1 255.255.255.255 Null0 ! ip prefix-list cymru-out-v4 seq 5 deny 0.0.0.0/0 le 32 ! ipv6 route 2001:DB8:0:DEAD:BEEF::1/128 Null0 ! ipv6 prefix-list cymru-out-v6 seq 5 deny ::/0 le 128 ! route-map CYMRUBOGONS-V6 permit 10 description IPv6 Filter bogons learned from cymru.com bogon route-servers match community 100 set ipv6 next-hop 2001:DB8:0:DEAD:BEEF::1 ! route-map CYMRUBOGONS-V4 permit 10 description IPv4 Filter bogons learned from cymru.com bogon route-servers match community 100 set ip next-hop 192.0.2.1 From johnl at iecc.com Sun Oct 7 01:14:37 2012 From: johnl at iecc.com (John Levine) Date: 7 Oct 2012 01:14:37 -0000 Subject: names are not numbers, was IPv4 address length technical design In-Reply-To: <20592.28334.622769.539587@world.std.com> Message-ID: <20121007011437.23783.qmail@joyce.lan> In article <20592.28334.622769.539587 at world.std.com> you write: >It's occured to you that FQDNs contain some structured information, >no? Hey, I've got a great idea. Let's lose this silly phone number portability nonsense and use phone numbers as routes. I mean, anyone who moves and takes his cell phone with him has only himself to blame, right? R's, John From bmanning at vacation.karoshi.com Sun Oct 7 02:20:45 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 7 Oct 2012 02:20:45 +0000 Subject: ESR muses on, among other things, the early IETF In-Reply-To: References: <12619088.28579.1349490048157.JavaMail.root@benjamin.baylink.com> <506FF681.1050300@foobar.org> <20121006103929.GA29606@vacation.karoshi.com.> Message-ID: <20121007022045.GA32028@vacation.karoshi.com.> On Sat, Oct 06, 2012 at 06:12:08PM -0400, Frank Kastenholz wrote: > > On Oct 6, 2012, at 6:39 AM, bmanning at vacation.karoshi.com wrote: > > > On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote: > >> On 06/10/2012 03:20, Jay Ashworth wrote: > >>> Those who know Fred and knew Jon personally might want to throw an oar in the > >>> water on this blog posting from last month.. > ... > > > I -think- Jon and Fred were not contemporaries. Fred is > > closer to my age than Jon. > > While I don't know how old either is/would be, Fred was active in the IETF before > I joined the IESG, I appointed him chair of the pppwg in 95 or 96 or so > (I think?) and he became IETF chair in 96 or so --- the last year I was on the IESG. > And was at the nerds on the beach IETF in Hawaii in89 or 90 iirc > --Jon. Passed away in 98. > > They certainly overlapped in their i* lives > > Frank Kastenholz > going back another decade, Fred and I both worked on/with bridging technologies, before routing was popular. Jon had us beat by at least a decade - early 1970s. We cme to the party in the late 70's early 80s. /bill From joe at nethead.com Sun Oct 7 02:43:27 2012 From: joe at nethead.com (Joe Hamelin) Date: Sat, 6 Oct 2012 19:43:27 -0700 Subject: names are not numbers, was IPv4 address length technical design In-Reply-To: <20121007011437.23783.qmail@joyce.lan> References: <20592.28334.622769.539587@world.std.com> <20121007011437.23783.qmail@joyce.lan> Message-ID: On Sat, Oct 6, 2012 at 6:14 PM, John Levine wrote: > > > Hey, I've got a great idea. Let's lose this silly phone number > portability nonsense and use phone numbers as routes. > You do not want to go down the hell hole that is SS7. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From walter.keen at rainierconnect.net Tue Oct 2 17:03:44 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Tue, 2 Oct 2012 10:03:44 -0700 (PDT) Subject: Cost of fiber run between neighbouring office buildings In-Reply-To: <86y5jox1jy.fsf@seastrom.com> Message-ID: <1214515989.2096067.1349197424022.JavaMail.root@zimbra01.rainierconnect.net> Where I work for a local telecommunications provider, we will not run any fiber smaller than 24 strand, and these days that is a drop into a building. When talking about single mode fiber, the cost per foot difference in 2, 8, or even 24 strand is typically a matter of less than $1 per foot. Some of the prices I've seen lately on google indicate about $.4/ft for 2-strand, $.5/ft for 6-strand, and $1.8/ft for 24-strand It's all about the cost of getting it run by a contractor (which is typical if you have to get conduit installed, or run along telephone/power poles aerial) , unless you're in a position to do it yourself. You'd likely have to pay someone to terminate it into a patch panel for you, but it may be cheaper for them to do all strands at once as opposed to having them come back later. ----- Original Message ----- From: "Robert E. Seastrom" To: "Nick Hilliard" Cc: "NANOG" Sent: Tuesday, October 2, 2012 9:48:33 AM Subject: Re: Cost of fiber run between neighbouring office buildings Second what Nick said. Also, get quotes for double, quadruple, and more of the number of fibers you think you need today. If it makes economic sense to leave strands unterminated (coil neatly in the splice tray and have someone term later) by all means do it. Extra strands in the cable are almost free compared to the labor to pull it in. -r Nick Hilliard writes: > On 02/10/2012 13:35, Hank Disuko wrote: >> - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox Fiber cables >> - Distance of run is approx 520 meters > > For that length, go with single-mode. 10G-LR will happily run on 10km of > SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant > like this is totally pointless. Using MMF for anything outside your > cabinet / small cage is creating a legacy deployment on day 1 which will > bite you in future years. > > To answer the question you asked: if the ducts are already in place and > you're just pulling fibre through, you should have a breakdown in terms of > # of terminations + the manpower required to handle the pull + cable > finishing. I.e. it shouldn't be very much. If you need ducting laid or if > your existing ducting is in poor shape, that's a different issue. > > Nick From george.herbert at gmail.com Sun Oct 7 07:37:38 2012 From: george.herbert at gmail.com (George Herbert) Date: Sun, 7 Oct 2012 00:37:38 -0700 Subject: IPv4 address length technical design In-Reply-To: <20592.31220.78712.550345@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> Message-ID: <1483EDBE-80A4-4F8B-9F09-4985D05EADF5@gmail.com> On Oct 6, 2012, at 11:35 AM, Barry Shein wrote: > > We can map from host names to ip addresses to routing actions, right? > > So clearly they're not unrelated or independent variables. There's a > smooth function from hostname->ipaddr->routing. No. Not just no, but hell no at the asserted communativity there, Barry. That's not even Wrong... And that's the point. DNS to IP is in no way a smooth function. Hell no, for many networks. It's only true for the boringest customers. Try actual enterprise endpoints, or service providers. IP to Routing is not smooth at predictable scales. Yes, it's in blocks, but a top-down view is at best fractal discontinuity. IP to routing is smoother in IPv6 but as routing has two components - physical location and net path - was made smoother in one only ( net path, and to the degree that's smooth in physical location by accident...). George William Herbert Sent from my iPhone From nick at foobar.org Sun Oct 7 10:40:13 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 07 Oct 2012 11:40:13 +0100 Subject: 100.100.0.0/24 In-Reply-To: References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> <20121006203724.GA26642@panix.com> <1349566279.5173.4.camel@nymphadora.home.ludost.net> Message-ID: <50715C0D.2010303@foobar.org> On 07/10/2012 00:34, Randy Bush wrote: > ipv6 route 2001:DB8:0:DEAD:BEEF::1/128 Null0 plug: rfc 6666. 100::/64 is reserved for this purpose. Nick From bill at herrin.us Sun Oct 7 17:17:17 2012 From: bill at herrin.us (William Herrin) Date: Sun, 7 Oct 2012 13:17:17 -0400 Subject: IPv4 address length technical design In-Reply-To: <20592.28334.622769.539587@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> Message-ID: On Sat, Oct 6, 2012 at 1:47 PM, Barry Shein wrote: > It's occured to you that FQDNs contain some structured information, > no? It has occurred to me that the name on my shirt's tag contains some structured information. That doesn't make it particularly well suited for use as a computer network routing key. Or suited at all. On Sat, Oct 6, 2012 at 2:35 PM, Barry Shein wrote: > you can take a new idea and run with it a bit, or just > resist it right from the start. Intentionally crashing the moon into the earth is a new idea. How far should we run with it before concluding that it not only isn't a very good one, considering it hasn't taught us anything we didn't already know? > Van Jacobson had a similar observation vis a vis TCP and PPP header > compression, why keep sending the same bits back and forth over a PPP > link for example? Why not just an encapsulation which says "same as > previous"? > > Now, how can that be generalized? By observing that within a restricted subset of a problem domain there may be usable techniques that aren't portable to the broader problem domain. This is not news, and your comments have not bounded a subset of the routing problem domain in a way that would make a discussion of names as routing keys interesting. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bzs at world.std.com Sun Oct 7 19:52:25 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 7 Oct 2012 15:52:25 -0400 Subject: IPv4 address length technical design In-Reply-To: References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> Message-ID: <20593.56697.240514.316192@world.std.com> Ok, then let's take a step back, perhaps not permanently, and say DNS resolution is only really useful for routers with more than just a single default external route. So DNS could be reduced to an inter-router only protocol, similar to BGP in some sense. I suppose one question is how do we discover non-existant hostnames but we have strong analogues to that at the ICMP level already, host unreachable etc, just another kind of error feedback. But I'll agree that begs some thought. As I said, the proposal was originally offered by me to a bunch of young "hackers" in Singapore for the purpose of stimulating discussion. -- -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 Sun Oct 7 20:05:09 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 7 Oct 2012 16:05:09 -0400 Subject: names are not numbers, was IPv4 address length technical design In-Reply-To: <20121007011437.23783.qmail@joyce.lan> References: <20592.28334.622769.539587@world.std.com> <20121007011437.23783.qmail@joyce.lan> Message-ID: <20593.57461.950731.986876@world.std.com> Back in the 80s when DNS was a fairly new idea and things like Google were way in the future I remember suggesting on the TCP-IP list that people grab a phone number they owned as a domain name and add first_last as a mailbox so we could leverage the international phone directory system to find each other. For example something like barry_shein at 0016176403067.com (maybe insert a letter, all-digits wasn't allowed back then.) I guess that sort of idea was eventually incorporated into telephone number mapping but not clear how successful that is or if the intent is really the same. I think there were other analogues? http://en.wikipedia.org/wiki/Telephone_number_mapping But the idea has come up. -- -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 snoble at sonn.com Sun Oct 7 20:16:26 2012 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Oct 2012 13:16:26 -0700 Subject: IPv4 address length technical design In-Reply-To: <20593.56697.240514.316192@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> <20593.56697.240514.316192@world.std.com> Message-ID: <3B7A62FE-AF9C-49AA-9A49-14508B073315@sonn.com> On Oct 7, 2012, at 12:52 PM, Barry Shein wrote: > > Ok, then let's take a step back, perhaps not permanently, and say DNS > resolution is only really useful for routers with more than just a > single default external route. > > So DNS could be reduced to an inter-router only protocol, similar to > BGP in some sense. LISP DDT uses a lookup to determine EID location. From tal at whatexit.org Sun Oct 7 20:47:18 2012 From: tal at whatexit.org (Tom Limoncelli) Date: Sun, 7 Oct 2012 16:47:18 -0400 Subject: Typical additional latency for CGN? Message-ID: Have there been studies on how much latency CGN adds to a typical internet user? I'd also be interested in anecdotes. I've seen theoretical predictions but by now we should have measurements from early-world deployments. Thanks, Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos From george.herbert at gmail.com Sun Oct 7 20:56:37 2012 From: george.herbert at gmail.com (George Herbert) Date: Sun, 7 Oct 2012 13:56:37 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: Ancedotally, for users of an e-gadget company's website, cellphone company's outbound web proxies, internet games company, and image-intensive home furnishings website, the CGNs delivered content faster than the main website could, regardless of increasing its bandwidth. Latency problems with the CGNs were less than the main websites' latency problems, on the average. There were days that was not true, and days we had to re-re-re-reset the CGN contents, and the day the @#$#@$% game programmers screwed up the CGN calls, but on the whole it was among the least performance limiting / impeding features of the sites in question. -george On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: > Have there been studies on how much latency CGN adds to a typical > internet user? I'd also be interested in anecdotes. > > I've seen theoretical predictions but by now we should have > measurements from early-world deployments. > > Thanks, > Tom > > -- > Speaking at MacTech Conference 2012. http://mactech.com/conference > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my videos > -- -george william herbert george.herbert at gmail.com From jlewis at lewis.org Sun Oct 7 21:30:09 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 7 Oct 2012 17:30:09 -0400 (EDT) Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: I think you've confused CGN with CDN. On Sun, 7 Oct 2012, George Herbert wrote: > Ancedotally, for users of an e-gadget company's website, cellphone > company's outbound web proxies, internet games company, and > image-intensive home furnishings website, the CGNs delivered content > faster than the main website could, regardless of increasing its > bandwidth. Latency problems with the CGNs were less than the main > websites' latency problems, on the average. > > There were days that was not true, and days we had to re-re-re-reset > the CGN contents, and the day the @#$#@$% game programmers screwed up > the CGN calls, but on the whole it was among the least performance > limiting / impeding features of the sites in question. > > > -george > > On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. >> >> I've seen theoretical predictions but by now we should have >> measurements from early-world deployments. >> >> Thanks, >> Tom >> >> -- >> Speaking at MacTech Conference 2012. http://mactech.com/conference >> http://EverythingSysadmin.com -- my blog >> http://www.TomOnTime.com -- my videos >> > > > > -- > -george william herbert > george.herbert at gmail.com > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From james.cutler at consultant.com Sun Oct 7 21:30:33 2012 From: james.cutler at consultant.com (Cutler James R) Date: Sun, 7 Oct 2012 17:30:33 -0400 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: <062D8386-5CC5-4032-BBE6-4D00A6B9C2AF@consultant.com> On Oct 7, 2012, at 4:56 PM, George Herbert wrote: > Ancedotally, for users of an e-gadget company's website, cellphone > company's outbound web proxies, internet games company, and > image-intensive home furnishings website, the CGNs delivered content > faster than the main website could, regardless of increasing its > bandwidth. Latency problems with the CGNs were less than the main > websites' latency problems, on the average. > > There were days that was not true, and days we had to re-re-re-reset > the CGN contents, and the day the @#$#@$% game programmers screwed up > the CGN calls, but on the whole it was among the least performance > limiting / impeding features of the sites in question. > > > -george > > On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. >> >> I've seen theoretical predictions but by now we should have >> measurements from early-world deployments. >> >> Thanks, >> Tom >> >> -- >> Speaking at MacTech Conference 2012. http://mactech.com/conference >> http://EverythingSysadmin.com -- my blog >> http://www.TomOnTime.com -- my videos Huh? I had presumed that CGN was Carrier Grade NAT, not a proxy service. Help me understand. James R. Cutler james.cutler at consultant.com From tknchris at gmail.com Sun Oct 7 21:32:41 2012 From: tknchris at gmail.com (chris) Date: Sun, 7 Oct 2012 17:32:41 -0400 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: Or maybe SDN ? So many acronyms to choose from On Oct 7, 2012 5:31 PM, "Jon Lewis" wrote: > I think you've confused CGN with CDN. > > On Sun, 7 Oct 2012, George Herbert wrote: > > Ancedotally, for users of an e-gadget company's website, cellphone >> company's outbound web proxies, internet games company, and >> image-intensive home furnishings website, the CGNs delivered content >> faster than the main website could, regardless of increasing its >> bandwidth. Latency problems with the CGNs were less than the main >> websites' latency problems, on the average. >> >> There were days that was not true, and days we had to re-re-re-reset >> the CGN contents, and the day the @#$#@$% game programmers screwed up >> the CGN calls, but on the whole it was among the least performance >> limiting / impeding features of the sites in question. >> >> >> -george >> >> On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: >> >>> Have there been studies on how much latency CGN adds to a typical >>> internet user? I'd also be interested in anecdotes. >>> >>> I've seen theoretical predictions but by now we should have >>> measurements from early-world deployments. >>> >>> Thanks, >>> Tom >>> >>> -- >>> Speaking at MacTech Conference 2012. http://mactech.com/conference >>> http://EverythingSysadmin.com -- my blog >>> http://www.TomOnTime.com -- my videos >>> >>> >> >> >> -- >> -george william herbert >> george.herbert at gmail.com >> >> > ------------------------------**------------------------------**---------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ > > From george.herbert at gmail.com Sun Oct 7 21:55:02 2012 From: george.herbert at gmail.com (George Herbert) Date: Sun, 7 Oct 2012 14:55:02 -0700 Subject: Typical additional latency for CGN? In-Reply-To: <062D8386-5CC5-4032-BBE6-4D00A6B9C2AF@consultant.com> References: <062D8386-5CC5-4032-BBE6-4D00A6B9C2AF@consultant.com> Message-ID: Sorry, at a conference and not paying enough attention to email. My bad. -george On Sun, Oct 7, 2012 at 2:30 PM, Cutler James R wrote: > On Oct 7, 2012, at 4:56 PM, George Herbert wrote: >> Ancedotally, for users of an e-gadget company's website, cellphone >> company's outbound web proxies, internet games company, and >> image-intensive home furnishings website, the CGNs delivered content >> faster than the main website could, regardless of increasing its >> bandwidth. Latency problems with the CGNs were less than the main >> websites' latency problems, on the average. >> >> There were days that was not true, and days we had to re-re-re-reset >> the CGN contents, and the day the @#$#@$% game programmers screwed up >> the CGN calls, but on the whole it was among the least performance >> limiting / impeding features of the sites in question. >> >> >> -george >> >> On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: >>> Have there been studies on how much latency CGN adds to a typical >>> internet user? I'd also be interested in anecdotes. >>> >>> I've seen theoretical predictions but by now we should have >>> measurements from early-world deployments. >>> >>> Thanks, >>> Tom >>> >>> -- >>> Speaking at MacTech Conference 2012. http://mactech.com/conference >>> http://EverythingSysadmin.com -- my blog >>> http://www.TomOnTime.com -- my videos > > Huh? I had presumed that CGN was Carrier Grade NAT, not a proxy service. Help me understand. > > James R. Cutler > james.cutler at consultant.com > > > > > > > -- -george william herbert george.herbert at gmail.com From cb.list6 at gmail.com Sun Oct 7 22:18:56 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 7 Oct 2012 15:18:56 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: > > Have there been studies on how much latency CGN adds to a typical > internet user? I'd also be interested in anecdotes. > Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not meaningfully add latency. CGN is not enough of a factor to impact happy eyeballs in a way that improves ipv6 use. > I've seen theoretical predictions but by now we should have > measurements from early-world deployments. > Most mobile providers have been doing what is commonly called cgn for 5 to 10 years. CGN is not a new concept or implementation for mobile. CB > Thanks, > Tom > > -- > Speaking at MacTech Conference 2012. http://mactech.com/conference > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my videos > From pvinci at VinciConsulting.com Sun Oct 7 22:20:28 2012 From: pvinci at VinciConsulting.com (Paul Vinciguerra) Date: Sun, 7 Oct 2012 22:20:28 +0000 Subject: IPv4 address length technical design In-Reply-To: <3B7A62FE-AF9C-49AA-9A49-14508B073315@sonn.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> <20593.56697.240514.316192@world.std.com> <3B7A62FE-AF9C-49AA-9A49-14508B073315@sonn.com> Message-ID: <6E5736BD68F770449C74FBAD975F807C927291FD@NYDC-EXCH01.vinci-consulting-corp.local> > > Ok, then let's take a step back, perhaps not permanently, and say DNS > resolution is only really useful for routers with more than just a > single default external route. > > So DNS could be reduced to an inter-router only protocol, similar to > BGP in some sense. LISP DDT uses a lookup to determine EID location. We operate one of the DDT roots, and yes the difference is that LISP uses an on-demand pull mechanism, where the route is looked up and then cached until it ages out from inactivity. BGP pushes every route to peers and everyone running BGP pays a hardware tax for carrying each and every route. (See Bill Herrin's work at http://bill.herrin.us/network/bgpcost.html) DDT provides a scalable, distributed database similar to DNS for looking up prefixes in LISP mapping servers. From jra at baylink.com Mon Oct 8 00:08:56 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Oct 2012 20:08:56 -0400 (EDT) Subject: IPv4 address length technical design In-Reply-To: <20592.31220.78712.550345@world.std.com> Message-ID: <32317890.28932.1349654936971.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > Well, George, you can take a new idea and run with it a bit, or just > resist it right from the start. > > We can map from host names to ip addresses to routing actions, right? > > So clearly they're not unrelated or independent variables. There's a > smooth function from hostname->ipaddr->routing. Ah. *This* is where you fell off the horse. Nope; the first one isn't smooth; it's *completely arbitrary*. The mapping is, in fact, DNS's raison d'etre. The second one has a relatively smooth mapping *at any given point in time*, but you can't fit a function to that; it is prone also to arbitrary changes over time. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Sun Oct 7 21:31:10 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Oct 2012 14:31:10 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: Of all the problems CGN creates, I would think that latency is in the noise compared to the other issues. Owen On Oct 7, 2012, at 1:56 PM, George Herbert wrote: > Ancedotally, for users of an e-gadget company's website, cellphone > company's outbound web proxies, internet games company, and > image-intensive home furnishings website, the CGNs delivered content > faster than the main website could, regardless of increasing its > bandwidth. Latency problems with the CGNs were less than the main > websites' latency problems, on the average. > > There were days that was not true, and days we had to re-re-re-reset > the CGN contents, and the day the @#$#@$% game programmers screwed up > the CGN calls, but on the whole it was among the least performance > limiting / impeding features of the sites in question. > > > -george > > On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli wrote: >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. >> >> I've seen theoretical predictions but by now we should have >> measurements from early-world deployments. >> >> Thanks, >> Tom >> >> -- >> Speaking at MacTech Conference 2012. http://mactech.com/conference >> http://EverythingSysadmin.com -- my blog >> http://www.TomOnTime.com -- my videos >> > > > > -- > -george william herbert > george.herbert at gmail.com From owen at delong.com Mon Oct 8 00:42:11 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Oct 2012 17:42:11 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> On Oct 7, 2012, at 3:18 PM, Cameron Byrne wrote: > On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: >> >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. >> > > Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not > meaningfully add latency. CGN is not enough of a factor to impact happy > eyeballs in a way that improves ipv6 use. > >> I've seen theoretical predictions but by now we should have >> measurements from early-world deployments. >> > > Most mobile providers have been doing what is commonly called cgn for 5 to > 10 years. CGN is not a new concept or implementation for mobile. > True, but, as we have discussed before, mobile users, especially in the US, have dramatically lowered expectations of internet access from their mobile devices vs. what they expect from a household ISP. We expect half the services we want to be crippled by mobile carriers because they don't like competition. We file lawsuits when that happens on our terrestrial connections. Owen From jlewis at lewis.org Mon Oct 8 01:22:54 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 7 Oct 2012 21:22:54 -0400 (EDT) Subject: Typical additional latency for CGN? In-Reply-To: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> Message-ID: On Sun, 7 Oct 2012, Owen DeLong wrote: >> Most mobile providers have been doing what is commonly called cgn for 5 to >> 10 years. CGN is not a new concept or implementation for mobile. > > True, but, as we have discussed before, mobile users, especially in the US, > have dramatically lowered expectations of internet access from their mobile > devices vs. what they expect from a household ISP. Speaking of which, has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) connections? AFAIK, AT&T mobile does CGN. It's puzzling that they'd block outgoing ssh when there have been multiple ssh clients in the Apple app store for years. I used to be able to ssh from my AT&T phone. I found recently, the packets don't get to the server unless I VPN from the phone first (or am on wifi, not relying on AT&T for IP). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tomb at byrneit.net Mon Oct 8 02:46:11 2012 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 7 Oct 2012 19:46:11 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <20120917233210.61755.qmail@joyce.lan> <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> Message-ID: <72F9A69DCF990443B2CEC064E605CE064A8270@Pascal.zaphodb.org> Or just use their IP address as a useful universal identifier, which is kind of the point of V6. Whether you can be routed to isn't the point. It's that, if/when you can, there is an address, and it's easy to assign/divine, that you can be reached at, is. > -----Original Message----- > From: George Herbert [mailto:george.herbert at gmail.com] > Sent: Friday, September 28, 2012 11:17 PM > To: John R. Levine; George Herbert > Cc: Tomas L. Byrnes; nanog at nanog.org > Subject: Re: IPv6 Ignorance > > My customer the Dark Matter local galaxy group beg to disagree; just > because you cannot see them does not mean that you cannot feel them > gravitationally. > > Or route to them. > > > George William Herbert > Sent from my iPhone > > On Sep 28, 2012, at 10:31 PM, "John R. Levine" wrote: > > >> You won't have enough addresses for Dark Matter, Neutrinos, etc. > >> Atoms wind up using up about 63 bits (2^10^82) based on the current > >> SWAG. The missing mass is 84% of the universe. > > > > Fortunately, until we find it, it doesn't need addresses. > > > >> > >>> -----Original Message----- > >>> From: Randy Bush [mailto:randy at psg.com] > >>> Sent: Monday, September 17, 2012 8:30 PM > >>> To: John Levine > >>> Cc: nanog at nanog.org > >>> Subject: Re: IPv6 Ignorance > >>> > >>>> In technology, not much. But I'd be pretty surprised if the laws > >>>> of arithmetic were to change, or if we were to find it useful to > >>>> assign IP addresses to objects smaller than a single atom. > >>> > >>> we assign them /64s > > > > Regards, > > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > > Dummies", Please consider the environment before reading this e-mail. > > http://jl.ly > > From bill at herrin.us Mon Oct 8 03:11:26 2012 From: bill at herrin.us (William Herrin) Date: Sun, 7 Oct 2012 23:11:26 -0400 Subject: IPv4 address length technical design In-Reply-To: <20593.56697.240514.316192@world.std.com> References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> <20592.31220.78712.550345@world.std.com> <20593.56697.240514.316192@world.std.com> Message-ID: On Sun, Oct 7, 2012 at 3:52 PM, Barry Shein wrote: > Ok, then let's take a step back, perhaps not permanently, and say DNS > resolution is only really useful for routers with more than just a > single default external route. > > So DNS could be reduced to an inter-router only protocol, similar to > BGP in some sense. There's no party in the neighborhood you're searching. Turn it upside down, on the other hand, and you end up somewhere like TRRP. http://bill.herrin.us/network/trrp.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From aj at sneep.net Mon Oct 8 07:04:08 2012 From: aj at sneep.net (Alastair Johnson) Date: Mon, 08 Oct 2012 00:04:08 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: <50727AE8.1010501@sneep.net> On 10/7/2012 1:47 PM, Tom Limoncelli wrote: > Have there been studies on how much latency CGN adds to a typical > internet user? I'd also be interested in anecdotes. You are typically talking microseconds of additional latency for sessions transiting a CGN/LSN type node. aj From dr at cluenet.de Mon Oct 8 09:27:09 2012 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 8 Oct 2012 11:27:09 +0200 Subject: Typical additional latency for CGN? In-Reply-To: References: Message-ID: <20121008092709.GA32240@srv03.cluenet.de> On Sun, Oct 07, 2012 at 03:18:56PM -0700, Cameron Byrne wrote: > On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: > > > > Have there been studies on how much latency CGN adds to a typical > > internet user? I'd also be interested in anecdotes. > > > > Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not > meaningfully add latency. CGN is not enough of a factor to impact happy > eyeballs in a way that improves ipv6 use. Confirmed by my experience. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From tal at whatexit.org Mon Oct 8 11:46:21 2012 From: tal at whatexit.org (Tom Limoncelli) Date: Mon, 8 Oct 2012 07:46:21 -0400 Subject: Typical additional latency for CGN? In-Reply-To: <20121008092709.GA32240@srv03.cluenet.de> References: <20121008092709.GA32240@srv03.cluenet.de> Message-ID: On Mon, Oct 8, 2012 at 5:27 AM, Daniel Roesen wrote: > On Sun, Oct 07, 2012 at 03:18:56PM -0700, Cameron Byrne wrote: >> On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: >> > >> > Have there been studies on how much latency CGN adds to a typical >> > internet user? I'd also be interested in anecdotes. >> > >> >> Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not >> meaningfully add latency. CGN is not enough of a factor to impact happy >> eyeballs in a way that improves ipv6 use. > > Confirmed by my experience. Thanks for the info! Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos From joseph.snyder at gmail.com Mon Oct 8 12:39:36 2012 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Mon, 08 Oct 2012 08:39:36 -0400 Subject: Typical additional latency for CGN? In-Reply-To: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> Message-ID: Owen DeLong wrote: > >On Oct 7, 2012, at 3:18 PM, Cameron Byrne wrote: > >> On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: >>> >>> Have there been studies on how much latency CGN adds to a typical >>> internet user? I'd also be interested in anecdotes. >>> >> >> Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does >not >> meaningfully add latency. CGN is not enough of a factor to impact >happy >> eyeballs in a way that improves ipv6 use. >> >>> I've seen theoretical predictions but by now we should have >>> measurements from early-world deployments. >>> >> >> Most mobile providers have been doing what is commonly called cgn for >5 to >> 10 years. CGN is not a new concept or implementation for mobile. >> > >True, but, as we have discussed before, mobile users, especially in the >US, >have dramatically lowered expectations of internet access from their >mobile >devices vs. what they expect from a household ISP. > >We expect half the services we want to be crippled by mobile carriers >because >they don't like competition. We file lawsuits when that happens on our >terrestrial connections. > >Owen Except now you have to do mediation, since class action lawsuits are now null and void. :) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From dot at dotat.at Mon Oct 8 17:47:36 2012 From: dot at dotat.at (Tony Finch) Date: Mon, 8 Oct 2012 18:47:36 +0100 Subject: IPv4 address length technical design In-Reply-To: References: <20591.31343.30301.633043@world.std.com> <20592.28334.622769.539587@world.std.com> Message-ID: <9B84B407-12AA-444D-9584-28F68858F746@dotat.at> On 7 Oct 2012, at 18:17, William Herrin wrote: > > Intentionally crashing the moon into the earth is a new idea. How far > should we run with it before concluding that it not only isn't a very > good one, considering it hasn't taught us anything we didn't already > know? http://www.xent.com/FoRK-archive/july98/0041.html Tony. -- f.anthony.n.finch http://dotat.at/ From dot at dotat.at Mon Oct 8 17:53:57 2012 From: dot at dotat.at (Tony Finch) Date: Mon, 8 Oct 2012 18:53:57 +0100 Subject: IPv4 address length technical design In-Reply-To: <506F8532.4050803@mtcc.com> References: <20591.31343.30301.633043@world.std.com> <506F8532.4050803@mtcc.com> Message-ID: On 6 Oct 2012, at 02:11, Michael Thomas wrote: > > Wasn't David Cheriton proposing something like this? > > http://www-dsg.stanford.edu/triad/ CCNx basically routes on URLs http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf Tony. -- f.anthony.n.finch http://dotat.at/ From Dave.Siegel at level3.com Mon Oct 8 18:58:51 2012 From: Dave.Siegel at level3.com (Siegel, David) Date: Mon, 8 Oct 2012 18:58:51 +0000 Subject: IPv4 address length technical design In-Reply-To: <20591.31343.30301.633043@world.std.com> References: <20591.31343.30301.633043@world.std.com> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90ED33295@W8USSFJ204.ams.gblxint.com> I'll identify myself as the person who asked you the question privately. Unfortunately, Barry, I still don't see a problem statement in your response. It sounds to me as though it really is nothing more than an interesting thought experiment, and there's nothing wrong with that at all as long as we all acknowledge the purpose of the discussion. :-) Dave -----Original Message----- From: Barry Shein [mailto:bzs at world.std.com] Sent: Friday, October 05, 2012 6:25 PM To: nanog at nanog.org Cc: Barry Shein Subject: RE: IPv4 address length technical design > While this is an interesting thought experiment, what problem are > you trying to solve with this proposal? (asked privately but it seems worthwhile answering publicly, bcc'd, you can id yourself if you like.) Look, as I said in the original message I was asked to speak to a group of young "hackers" at the HackerSpace in Singapore. I wanted to be interesting and thought-provoking, make them think through how this stuff works for an hour or two, encourage them to poke holes in it, etc. It was one of the audience who pointed out the potential MTU problem. What problem does it solve, potentially? 0. Despite fears expressed herein I am not single-handedly planning to convert the worldwide internet to this over the weekend. I'm going to need some help :-) 1. It eliminates the need for DNS in its generally used form. Sure, we've overloaded DNS with other functions from SPF -- in fact it was Meng Weng Wong, inventor of SPF, who graciously invited me to speak -- to whatever. But that's begging the point, there's nothing interesting here about distributed, lightweight databases other than eliminating one. Keep the DNS protocol per se for those things if you like. But given this you won't need to translate between host names and addresses which is really what DNS was invented to do. 2. It makes "addresses" more transparent to humans, particularly when you consider ipv6 addresses as typically displayed (hex.) Is this an important goal? Not sure, but it's certainly true. 3. It's a transfinite space. That just means that like Dewey Decimal etc it can be arbitrarily expanded, you can add more levels or even stick levels in between plus or minus some rules regarding SLDs/TLDs, and other rules which might or might not be imposed (see #4). But its total address space is as large as you allow a payload, there is nothing inherent in the scheme that limits the addressing other than the permutation of all acceptable Unicode glyphs I guess. But since one can also have numeric parts and the set of integers is infinite (that's tongue-in-cheek, somewhat.) 4. Also, because it's transfinite it's arbitrarily segmentable. Again, that just means you can impose any meaning you like on any substring or set of substrings. So for example host.gTLD is generally taken to be something of some significance, or host.co.ccTLD, and that sort of idea can be applied as needed, or not at all. 5. Bits is bits. I don't know how to say that more clearly. An ipv6 address is a string of 128 bits with some segmentation implications (net part, host part.) A host name is a string of bits of varying length. But it's still just ones and zeros, an integer, however you want to read it. The discussion I was responding to on NANOG involved how we got here and where might we be going. I brought up an idea I'd worked out somewhat and have even presented in a small but public forum as being a possible future to consider further. Now you can go back to your regularly scheduled Jim Fleming guffawing. -- -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 eric.rosenberry at iovation.com Mon Oct 8 19:06:45 2012 From: eric.rosenberry at iovation.com (Eric Rosenberry) Date: Mon, 8 Oct 2012 12:06:45 -0700 Subject: Multiple Sprint Outages? Message-ID: Looks like Sprint is having a very bad day today in the NW? Anybody able to elaborate on exactly where these fiber cuts are and exactly what is impacted? I see mention of several different places that things may be cut right now... We saw sporadic readability issues this AM until we downed our connection to Sprint. http://www.datacenterknowledge.com/archives/2012/10/08/cable-cut-in-midwest-hobbles-alaska-airlines/ http://techcrunch.com/2012/10/08/sprint-voice-data-down-in-minnesota-washington-oregon-alaska-airlines-flights-delayed/ -Eric -- *Eric Rosenberry* Sr. Infrastructure Architect // Chief Bit Plumber From virendra.rode at gmail.com Mon Oct 8 19:18:22 2012 From: virendra.rode at gmail.com (virendra rode) Date: Mon, 08 Oct 2012 12:18:22 -0700 Subject: Multiple Sprint Outages? In-Reply-To: References: Message-ID: <507326FE.6080102@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/08/2012 12:06 PM, Eric Rosenberry wrote: > Looks like Sprint is having a very bad day today in the NW? > > Anybody able to elaborate on exactly where these fiber cuts are and exactly > what is impacted? I see mention of several different places that things > may be cut right now... > > We saw sporadic readability issues this AM until we downed our connection > to Sprint. > > http://www.datacenterknowledge.com/archives/2012/10/08/cable-cut-in-midwest-hobbles-alaska-airlines/ > > http://techcrunch.com/2012/10/08/sprint-voice-data-down-in-minnesota-washington-oregon-alaska-airlines-flights-delayed/ > > -Eric > - -------------------- http://tracker.outages.org/reports/view/48 regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlBzJv4ACgkQ3HuimOHfh+EvrQD/T9hRplTeA0Cqfs9Wt3BUNsc4 iAt2qELtbWZmF6AM+ZYA/3dIX0YRhA/J8rycF8isVvOq26zu2gt92jDxpLE0zfuy =+gyU -----END PGP SIGNATURE----- From george.herbert at gmail.com Mon Oct 8 19:19:38 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 8 Oct 2012 12:19:38 -0700 Subject: Multiple Sprint Outages? In-Reply-To: References: Message-ID: Yes, multiple reports on the outages list, which you should also join. Short summary: WI and Washington state separate fiber cuts. -george On Mon, Oct 8, 2012 at 12:06 PM, Eric Rosenberry wrote: > Looks like Sprint is having a very bad day today in the NW? > > Anybody able to elaborate on exactly where these fiber cuts are and exactly > what is impacted? I see mention of several different places that things > may be cut right now... > > We saw sporadic readability issues this AM until we downed our connection > to Sprint. > > http://www.datacenterknowledge.com/archives/2012/10/08/cable-cut-in-midwest-hobbles-alaska-airlines/ > > http://techcrunch.com/2012/10/08/sprint-voice-data-down-in-minnesota-washington-oregon-alaska-airlines-flights-delayed/ > > -Eric > > -- > *Eric Rosenberry* > Sr. Infrastructure Architect // Chief Bit Plumber -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Mon Oct 8 21:24:03 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 8 Oct 2012 14:24:03 -0700 Subject: Multiple Sprint Outages? In-Reply-To: References: Message-ID: As I have received multiple requests for this, blasting it out to the list: To sign up for the outages mailing list, go to: https://puck.nether.net/mailman/listinfo/outages https://puck.nether.net/mailman/listinfo/outages-discussion The website is www.outages.org but email maintenance / list management is at puck.nether.net (Jared Mauch) but managed by Vivendra Rode. -george william herbert george.herbert at gmail.com On Mon, Oct 8, 2012 at 12:19 PM, George Herbert wrote: > Yes, multiple reports on the outages list, which you should also join. > > Short summary: WI and Washington state separate fiber cuts. > > > -george > > On Mon, Oct 8, 2012 at 12:06 PM, Eric Rosenberry > wrote: >> Looks like Sprint is having a very bad day today in the NW? >> >> Anybody able to elaborate on exactly where these fiber cuts are and exactly >> what is impacted? I see mention of several different places that things >> may be cut right now... >> >> We saw sporadic readability issues this AM until we downed our connection >> to Sprint. >> >> http://www.datacenterknowledge.com/archives/2012/10/08/cable-cut-in-midwest-hobbles-alaska-airlines/ >> >> http://techcrunch.com/2012/10/08/sprint-voice-data-down-in-minnesota-washington-oregon-alaska-airlines-flights-delayed/ >> >> -Eric >> >> -- >> *Eric Rosenberry* >> Sr. Infrastructure Architect // Chief Bit Plumber > > > > -- > -george william herbert > george.herbert at gmail.com -- -george william herbert george.herbert at gmail.com From owen at delong.com Mon Oct 8 23:39:40 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Oct 2012 16:39:40 -0700 Subject: Typical additional latency for CGN? In-Reply-To: References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> Message-ID: <17526FD1-2B33-47A6-AA63-9510EDF7503D@delong.com> > > True, but, as we have discussed before, mobile users, especially in the US, > have dramatically lowered expectations of internet access from their mobile > devices vs. what they expect from a household ISP. > > We expect half the services we want to be crippled by mobile carriers because > they don't like competition. We file lawsuits when that happens on our > terrestrial connections. > > Owen > > > > Except now you have to do mediation, since class action lawsuits are now null and void. :) I'm not convinced that's actually true, however, even if you ignore the idea of a class-action, the more effective approach is a vast fleet of small-claims cases. Corporations are generally much better prepared and resourced to deal with mediation and/or class-actions. An influx of a huge number of small-claims actions in courts all over the place, OTOH, costs very little resources on the plaintiff side while having a much larger impact on the corporation, even if the corporation prevails in every case. Owen From Valdis.Kletnieks at vt.edu Tue Oct 9 02:29:41 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Oct 2012 22:29:41 -0400 Subject: Typical additional latency for CGN? In-Reply-To: Your message of "Sun, 07 Oct 2012 16:47:18 -0400." References: Message-ID: <50317.1349749781@turing-police.cc.vt.edu> On Sun, 07 Oct 2012 16:47:18 -0400, Tom Limoncelli said: > Have there been studies on how much latency CGN adds to a typical > internet user? I'd also be interested in anecdotes. Should we include the time spent talking to the help desk trying to resolve double-NAT'ing issues in the latency? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Tue Oct 9 03:12:13 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 8 Oct 2012 23:12:13 -0400 (EDT) Subject: [mailop] Complicated Mailinglist Setup In-Reply-To: <20121009030829.GA8456@gsp.org> Message-ID: <20008463.29352.1349752333623.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rich Kulawiec" > Any list-related traffic received on #2 will be forwarded to the MLM > and will be processed accordingly. Any list-related traffic generated > on #2 will be handed off to #1 for queueing and delivery. > > Is this what you were trying to accomplish? I predict he'll say yes. And I also think that if he's got one role-name in DNS for his actual mail server, and a separate role-name for his mail list service -- even though they're presently the same machine -- that this will be even easier; probably not requiring the special configuration at all. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Tue Oct 9 06:05:19 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 9 Oct 2012 01:05:19 -0500 Subject: Typical additional latency for CGN? In-Reply-To: <50317.1349749781@turing-police.cc.vt.edu> References: <50317.1349749781@turing-police.cc.vt.edu> Message-ID: On 10/8/12, Valdis.Kletnieks at vt.edu wrote: > On Sun, 07 Oct 2012 16:47:18 -0400, Tom Limoncelli said: >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. > Should we include the time spent talking to the help desk trying to resolve > double-NAT'ing issues in the latency? That's downtime to address the brokenness, or loss of availability >1% after you count time users waste trying to navigate large carriers' confusing telephone IVR mazes designed to obscure access to helpdesk, hold time, time waiting for callbacks, and finally, non-resolution of double-NAT issue without user paying extra for non-NAT IP; which is all different from network latency, and of much greater impact than a latency increase <0.1ms. -- -JH From cjp at 0x1.net Tue Oct 9 14:34:53 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 9 Oct 2012 10:34:53 -0400 Subject: Native IPv6 providers/datacenters list? Message-ID: <20121009143453.GA743@debian> I want to make an informed response to a comment made by our CenturyLink rep regarding IPv6, in the context of SAVVIS not being able to provide IPv6 at their DC3 facility: > There is only a handful of carriers that can provide that > service today and CenturyLink (Legacy Qwest) happen to be one > of them. Is there a list of native IPv6 providers out there somewhere, particularly one that includes hosting data centers (e.g., SAVVIS), with which I could cluebat^Wshare with my rep? Thanks, -cjp From ryan at u13.net Tue Oct 9 14:42:40 2012 From: ryan at u13.net (Ryan Rawdon) Date: Tue, 9 Oct 2012 09:42:40 -0500 Subject: Native IPv6 providers/datacenters list? In-Reply-To: <20121009143453.GA743@debian> References: <20121009143453.GA743@debian> Message-ID: <5E164EA7-4CBF-4A40-A9BB-2AD2A2439925@u13.net> On Oct 9, 2012, at 9:34 AM, Christopher J. Pilkington wrote: > I want to make an informed response to a comment made by our > CenturyLink rep regarding IPv6, in the context of SAVVIS not > being able to provide IPv6 at their DC3 facility: > >> There is only a handful of carriers that can provide that >> service today and CenturyLink (Legacy Qwest) happen to be one >> of them. > > Is there a list of native IPv6 providers out there somewhere, > particularly one that includes hosting data centers (e.g., > SAVVIS), with which I could cluebat^Wshare with my rep? > I'm not sure about a list of facilities, but here's a start for transit providers who should be able to provide IPv6 connectivity: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers > Thanks, > -cjp > From jared at puck.nether.net Tue Oct 9 15:05:29 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 9 Oct 2012 11:05:29 -0400 Subject: Native IPv6 providers/datacenters list? In-Reply-To: <5E164EA7-4CBF-4A40-A9BB-2AD2A2439925@u13.net> References: <20121009143453.GA743@debian> <5E164EA7-4CBF-4A40-A9BB-2AD2A2439925@u13.net> Message-ID: On Oct 9, 2012, at 10:42 AM, Ryan Rawdon wrote: > > On Oct 9, 2012, at 9:34 AM, Christopher J. Pilkington wrote: > >> I want to make an informed response to a comment made by our >> CenturyLink rep regarding IPv6, in the context of SAVVIS not >> being able to provide IPv6 at their DC3 facility: >> >>> There is only a handful of carriers that can provide that >>> service today and CenturyLink (Legacy Qwest) happen to be one >>> of them. >> >> Is there a list of native IPv6 providers out there somewhere, >> particularly one that includes hosting data centers (e.g., >> SAVVIS), with which I could cluebat^Wshare with my rep? >> > > I'm not sure about a list of facilities, but here's a start for transit providers who should be able to provide IPv6 connectivity: > > http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers I'll come out in public and say that sometimes a backbone supports it but the datacenter group does not. This is quite common core -> edge deployment strategy with network technology. Some technology can grow from the edges inward, but IPv6 is not a technology that does it [well]. I've been observing some big increases in IPv6 traffic (its no longer measured in Mbps as from years ago, but in Gbps). I'm waiting for it to approach a fair percentage of the IPv4 traffic but there are some big steps being made by the networks and edges to bridge this gap. - Jared From jlewis at lewis.org Tue Oct 9 17:11:38 2012 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 9 Oct 2012 13:11:38 -0400 (EDT) Subject: Typical additional latency for CGN? In-Reply-To: <50317.1349749781@turing-police.cc.vt.edu> References: <50317.1349749781@turing-police.cc.vt.edu> Message-ID: On Mon, 8 Oct 2012 Valdis.Kletnieks at vt.edu wrote: > On Sun, 07 Oct 2012 16:47:18 -0400, Tom Limoncelli said: >> Have there been studies on how much latency CGN adds to a typical >> internet user? I'd also be interested in anecdotes. > > Should we include the time spent talking to the help desk trying to resolve > double-NAT'ing issues in the latency? That's a different sort of latency, and from what I've heard, it's often measured in days rather than fractional seconds. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Tue Oct 9 19:35:37 2012 From: bill at herrin.us (William Herrin) Date: Tue, 9 Oct 2012 15:35:37 -0400 Subject: Wired access to SMS? Message-ID: Hi Folks, I'm looking for a way to do wireline access to send and receive cellular phone short message service (SMS) messages. Despite all my google-fu, I have had limited luck finding anyone that meets my needs, so I'm hoping someone here has found the path through. My main criteria are: 1. Low quantity, high reliability. I'll want a few dozen phone numbers and effectively I'll be sending to and receiving from phones I own. 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically move numbers between the two locations for failover purposes. 3. U.S. based carrier. Tying in to the SMS system via Europe isn't acceptable to my customer. 4. Solution must reach phones on all U.S. cellular carriers. 5. Price is a very distant fifth criteria to the preceding four. I can consider Internet based systems where the provider uses U.S. based facilities and ties in to a U.S. phone network, provided that my standards of reliability and redundancy are met by their infrastructure. Alternately, I can also consider a wireless carrier that can provide two SIM-based phones with the same phone number for sending and receiving SMS messages. I'd put the sims in a pair of modems and manage deduplication of the received messages in software. Has anybody had any luck with this kind of requirement? Which vendors should I talk to and who at the vendor? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tim at lifelike.com Tue Oct 9 19:37:49 2012 From: tim at lifelike.com (Tim M Edwards) Date: Tue, 9 Oct 2012 12:37:49 -0700 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <5689085792276961524@unknownmsgid> Twillio.com On Oct 9, 2012, at 12:36 PM, William Herrin wrote: > Hi Folks, > > I'm looking for a way to do wireline access to send and receive > cellular phone short message service (SMS) messages. Despite all my > google-fu, I have had limited luck finding anyone that meets my needs, > so I'm hoping someone here has found the path through. My main > criteria are: > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. > > I can consider Internet based systems where the provider uses U.S. > based facilities and ties in to a U.S. phone network, provided that my > standards of reliability and redundancy are met by their > infrastructure. > > Alternately, I can also consider a wireless carrier that can provide > two SIM-based phones with the same phone number for sending and > receiving SMS messages. I'd put the sims in a pair of modems and > manage deduplication of the received messages in software. > > > Has anybody had any luck with this kind of requirement? Which vendors > should I talk to and who at the vendor? > > Thanks, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From lyle at lcrcomputer.net Tue Oct 9 19:54:51 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Tue, 09 Oct 2012 14:54:51 -0500 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <5074810B.3070901@lcrcomputer.net> On 10/09/12 14:35, William Herrin wrote: > Hi Folks, > > I'm looking for a way to do wireline access to send and receive > cellular phone short message service (SMS) messages. Despite all my > google-fu, I have had limited luck finding anyone that meets my needs, > so I'm hoping someone here has found the path through. My main > criteria are: > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. > > I can consider Internet based systems where the provider uses U.S. > based facilities and ties in to a U.S. phone network, provided that my > standards of reliability and redundancy are met by their > infrastructure. > > Alternately, I can also consider a wireless carrier that can provide > two SIM-based phones with the same phone number for sending and > receiving SMS messages. I'd put the sims in a pair of modems and > manage deduplication of the received messages in software. > > > Has anybody had any luck with this kind of requirement? Which vendors > should I talk to and who at the vendor? > > Thanks, > Bill Herrin > > If these are your phones, you will be controlling the carrier. If they are all one carrier, you can find out how to send to that carrier. For other uses where you don't control the carrier, it becomes a nightmare and where you may want to get a service provider to do that for you. Most carriers have a way to send messages directly to phones and I use a phone from one specific carrier that has access via modems(using TAP protocol and I use qpage(www.qpage.org)). You can also use qpage via a public(but carrier specific) snpp server, but I have not had a need for that as I need/want off Internet delivery of messages to the carrier's network. On the expensive side, lookup 'sms short code' and you will see information on how that works and more info on service providers in this area. Lyle Giese LCR Computer Services, Inc. From steve at pirk.com Tue Oct 9 21:05:38 2012 From: steve at pirk.com (steve pirk [egrep]) Date: Tue, 9 Oct 2012 14:05:38 -0700 Subject: Wired access to SMS? In-Reply-To: <5074810B.3070901@lcrcomputer.net> References: <5074810B.3070901@lcrcomputer.net> Message-ID: Have you looked at Google Voice much? I have mine set up to SMS all my devices, including email delivery, and can enable/disable devices as needed. The big benefit, is that I have an inbox full of all my old inbound and outbound text messages. It might be that I am missing a key element, but it looks like you want a virtual (VoIP) SMS number, and be able to decide which devices in the US receive the messages. On Oct 9, 2012 12:56 PM, "Lyle Giese" wrote: > On 10/09/12 14:35, William Herrin wrote: > >> Hi Folks, >> >> I'm looking for a way to do wireline access to send and receive >> cellular phone short message service (SMS) messages. Despite all my >> google-fu, I have had limited luck finding anyone that meets my needs, >> so I'm hoping someone here has found the path through. My main >> criteria are: >> >> >> 1. Low quantity, high reliability. I'll want a few dozen phone numbers >> and effectively I'll be sending to and receiving from phones I own. >> 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically >> move numbers between the two locations for failover purposes. >> 3. U.S. based carrier. Tying in to the SMS system via Europe isn't >> acceptable to my customer. >> 4. Solution must reach phones on all U.S. cellular carriers. >> 5. Price is a very distant fifth criteria to the preceding four. >> >> I can consider Internet based systems where the provider uses U.S. >> based facilities and ties in to a U.S. phone network, provided that my >> standards of reliability and redundancy are met by their >> infrastructure. >> >> Alternately, I can also consider a wireless carrier that can provide >> two SIM-based phones with the same phone number for sending and >> receiving SMS messages. I'd put the sims in a pair of modems and >> manage deduplication of the received messages in software. >> >> >> Has anybody had any luck with this kind of requirement? Which vendors >> should I talk to and who at the vendor? >> >> Thanks, >> Bill Herrin >> >> >> If these are your phones, you will be controlling the carrier. If they > are all one carrier, you can find out how to send to that carrier. For > other uses where you don't control the carrier, it becomes a nightmare and > where you may want to get a service provider to do that for you. > > Most carriers have a way to send messages directly to phones and I use a > phone from one specific carrier that has access via modems(using TAP > protocol and I use qpage(www.qpage.org)). You can also use qpage via a > public(but carrier specific) snpp server, but I have not had a need for > that as I need/want off Internet delivery of messages to the carrier's > network. > > On the expensive side, lookup 'sms short code' and you will see > information on how that works and more info on service providers in this > area. > > Lyle Giese > LCR Computer Services, Inc. > > From jwininger at ifncom.net Tue Oct 9 21:44:28 2012 From: jwininger at ifncom.net (James Wininger) Date: Tue, 9 Oct 2012 21:44:28 +0000 Subject: IPAM - reference Message-ID: <11F93765-7505-4313-946A-89123E5D65DB@ifncom.net> We have been using IPPlan for quite some time now and are finding that we are simply starting to outgrow it. We have been looking at several other IPAM solutions and are starting to consider a purchase. The 6connect solution looks promising. If anyone has experience with this product and would be so include to share that, it would be greatly appreciated. Please contact off list. -- Jim Wininger From bill at herrin.us Tue Oct 9 21:47:56 2012 From: bill at herrin.us (William Herrin) Date: Tue, 9 Oct 2012 17:47:56 -0400 Subject: Wired access to SMS? In-Reply-To: References: <5074810B.3070901@lcrcomputer.net> Message-ID: On Tue, Oct 9, 2012 at 5:05 PM, steve pirk [egrep] wrote: > Have you looked at Google Voice much? I have mine set up to SMS all my > devices, including email delivery, and can enable/disable devices as > needed. The big benefit, is that I have an inbox full of all my old inbound > and outbound text messages. Hi Steve, Google voice is a fine service and if they sold it with an API, I might well buy it. As a free public service with a strictly unofficial API, I can't seriously consider using it in my product's critical path. I need a service whose provider is actually obligated to keep it working to the standard of resilience typical of the rest of my system. Let me put it another way: with google voice, google mail, google search you are not the customer. You're the product. I use gmail for my personal mail and I can live with that. For business services, I need to be the customer. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rvandolson at esri.com Tue Oct 9 22:13:30 2012 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 9 Oct 2012 15:13:30 -0700 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <20121009221330.GA12805@esri.com> On Tue, Oct 09, 2012 at 03:35:37PM -0400, William Herrin wrote: > Hi Folks, > > I'm looking for a way to do wireline access to send and receive > cellular phone short message service (SMS) messages. Despite all my > google-fu, I have had limited luck finding anyone that meets my needs, > so I'm hoping someone here has found the path through. My main > criteria are: > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. > > I can consider Internet based systems where the provider uses U.S. > based facilities and ties in to a U.S. phone network, provided that my > standards of reliability and redundancy are met by their > infrastructure. > > Alternately, I can also consider a wireless carrier that can provide > two SIM-based phones with the same phone number for sending and > receiving SMS messages. I'd put the sims in a pair of modems and > manage deduplication of the received messages in software. > > > Has anybody had any luck with this kind of requirement? Which vendors > should I talk to and who at the vendor? > > Thanks, > Bill Herrin We use the MultiTech MultiModem iSMS SF-100G linked up to an AT&T Wireless account. It has a RESTful API and can handle both transmission and reception of text messages. There are probably SaaS options out there, but have never explored. Thanks, Ray From bill at herrin.us Tue Oct 9 22:17:26 2012 From: bill at herrin.us (William Herrin) Date: Tue, 9 Oct 2012 18:17:26 -0400 Subject: Wired access to SMS? In-Reply-To: <20121009221330.GA12805@esri.com> References: <20121009221330.GA12805@esri.com> Message-ID: On Tue, Oct 9, 2012 at 6:13 PM, Ray Van Dolson wrote: > On Tue, Oct 09, 2012 at 03:35:37PM -0400, William Herrin wrote: >> Alternately, I can also consider a wireless carrier that can provide >> two SIM-based phones with the same phone number for sending and >> receiving SMS messages. I'd put the sims in a pair of modems and >> manage deduplication of the received messages in software. > > We use the MultiTech MultiModem iSMS SF-100G linked up to an AT&T > Wireless account. > > It has a RESTful API and can handle both transmission and reception of > text messages. Hi Ray, Have you figured out how to get AT&T to give you two SIMs with the same phone number? I'm using a different set of multitech modems now but I need the same, I guess the terminology is "SMS long code," at both sites. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike.lyon at gmail.com Tue Oct 9 22:19:02 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 9 Oct 2012 15:19:02 -0700 Subject: Wired access to SMS? In-Reply-To: References: <5074810B.3070901@lcrcomputer.net> Message-ID: AWS? http://aws.amazon.com/sns/ On Tue, Oct 9, 2012 at 2:47 PM, William Herrin wrote: > On Tue, Oct 9, 2012 at 5:05 PM, steve pirk [egrep] wrote: > > Have you looked at Google Voice much? I have mine set up to SMS all my > > devices, including email delivery, and can enable/disable devices as > > needed. The big benefit, is that I have an inbox full of all my old > inbound > > and outbound text messages. > > Hi Steve, > > Google voice is a fine service and if they sold it with an API, I > might well buy it. As a free public service with a strictly unofficial > API, I can't seriously consider using it in my product's critical > path. I need a service whose provider is actually obligated to keep it > working to the standard of resilience typical of the rest of my > system. > > Let me put it another way: with google voice, google mail, google > search you are not the customer. You're the product. I use gmail for > my personal mail and I can live with that. For business services, I > need to be the customer. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From rvandolson at esri.com Tue Oct 9 22:22:00 2012 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 9 Oct 2012 15:22:00 -0700 Subject: Wired access to SMS? In-Reply-To: References: <20121009221330.GA12805@esri.com> Message-ID: <20121009222200.GA12950@esri.com> On Tue, Oct 09, 2012 at 06:17:26PM -0400, William Herrin wrote: > On Tue, Oct 9, 2012 at 6:13 PM, Ray Van Dolson wrote: > > On Tue, Oct 09, 2012 at 03:35:37PM -0400, William Herrin wrote: > >> Alternately, I can also consider a wireless carrier that can provide > >> two SIM-based phones with the same phone number for sending and > >> receiving SMS messages. I'd put the sims in a pair of modems and > >> manage deduplication of the received messages in software. > > > > We use the MultiTech MultiModem iSMS SF-100G linked up to an AT&T > > Wireless account. > > > > It has a RESTful API and can handle both transmission and reception of > > text messages. > > Hi Ray, > > Have you figured out how to get AT&T to give you two SIMs with the > same phone number? I'm using a different set of multitech modems now > but I need the same, I guess the terminology is "SMS long code," at > both sites. > > Regards, > Bill Herrin Sorry, Bill -- not something we've had a need for so have never tried. :) Ray From ag4ve.us at gmail.com Tue Oct 9 22:22:46 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 9 Oct 2012 22:22:46 +0000 Subject: Wired access to SMS? In-Reply-To: References: <20121009221330.GA12805@esri.com> Message-ID: Huh, you'd think they'd have mvno contracts just for this ...? On Oct 9, 2012 6:19 PM, "William Herrin" wrote: > On Tue, Oct 9, 2012 at 6:13 PM, Ray Van Dolson > wrote: > > On Tue, Oct 09, 2012 at 03:35:37PM -0400, William Herrin wrote: > >> Alternately, I can also consider a wireless carrier that can provide > >> two SIM-based phones with the same phone number for sending and > >> receiving SMS messages. I'd put the sims in a pair of modems and > >> manage deduplication of the received messages in software. > > > > We use the MultiTech MultiModem iSMS SF-100G linked up to an AT&T > > Wireless account. > > > > It has a RESTful API and can handle both transmission and reception of > > text messages. > > Hi Ray, > > Have you figured out how to get AT&T to give you two SIMs with the > same phone number? I'm using a different set of multitech modems now > but I need the same, I guess the terminology is "SMS long code," at > both sites. > > Regards, > Bill Herrin > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From trejrco at gmail.com Tue Oct 9 22:25:05 2012 From: trejrco at gmail.com (TJ) Date: Tue, 9 Oct 2012 18:25:05 -0400 Subject: Wired access to SMS? In-Reply-To: References: <5074810B.3070901@lcrcomputer.net> Message-ID: On Tue, Oct 9, 2012 at 5:47 PM, William Herrin wrote: > On Tue, Oct 9, 2012 at 5:05 PM, steve pirk [egrep] wrote: > > Have you looked at Google Voice much? I have mine set up to SMS all my > > devices, including email delivery, and can enable/disable devices as > > needed. The big benefit, is that I have an inbox full of all my old > inbound > > and outbound text messages. > ++1 on Google Voice. > Hi Steve, > > Google voice is a fine service and if they sold it with an API, I > might well buy it. As a free public service with a strictly unofficial > API, I can't seriously consider using it in my product's critical > path. I need a service whose provider is actually obligated to keep it > working to the standard of resilience typical of the rest of my > system. > > Let me put it another way: with google voice, google mail, google > search you are not the customer. You're the product. I use gmail for > my personal mail and I can live with that. For business services, I > need to be the customer. > FWLIW - I think that is a bit harsh, even if mostly accurate. I love GVoice for sending & receiving texts across multiple devices, some of which aren't cellular - or wired - at all :). *(Also have phone calls ring not just my phones, but Skype and GChat as well ...)* /TJ From henry at AegisInfoSys.com Tue Oct 9 22:29:09 2012 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 9 Oct 2012 18:29:09 -0400 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <20121009222908.GC5476@nntp.AegisInfoSys.com> On Tue, Oct 09, 2012 at 15:35:37PM -0400, William Herrin wrote: > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. vitelity.com? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From steve at pirk.com Tue Oct 9 22:45:17 2012 From: steve at pirk.com (steve pirk [egrep]) Date: Tue, 9 Oct 2012 15:45:17 -0700 Subject: Wired access to SMS? In-Reply-To: References: <5074810B.3070901@lcrcomputer.net> Message-ID: I will need to look into the Google Apps for business part of the voice product. I have not really tried apps accounts yet. As far as APIs go, it looks like most are "unofficial", but there is community support. Check googlevoice.org and also code.google. com/p/pygooglevoice for examples of what can be accomplished today. The Canada part is a showstopper, but it should be fairly easy to use a for exit node in the US to allow you to sign up for a US number. I do know that US users can still call all of Canada for free through the end of this year. My gut feel is that the telcos are what is keeping Google from releasing the product to a broader audience, e.g. more countries than the US. On Oct 9, 2012 3:25 PM, "TJ" wrote: > On Tue, Oct 9, 2012 at 5:47 PM, William Herrin wrote: > >> On Tue, Oct 9, 2012 at 5:05 PM, steve pirk [egrep] >> wrote: >> > Have you looked at Google Voice much? I have mine set up to SMS all my >> > devices, including email delivery, and can enable/disable devices as >> > needed. The big benefit, is that I have an inbox full of all my old >> inbound >> > and outbound text messages. >> > > ++1 on Google Voice. > > > >> Hi Steve, >> >> Google voice is a fine service and if they sold it with an API, I >> might well buy it. As a free public service with a strictly unofficial >> API, I can't seriously consider using it in my product's critical >> path. I need a service whose provider is actually obligated to keep it >> working to the standard of resilience typical of the rest of my >> system. >> >> Let me put it another way: with google voice, google mail, google >> search you are not the customer. You're the product. I use gmail for >> my personal mail and I can live with that. For business services, I >> need to be the customer. >> > > > FWLIW - I think that is a bit harsh, even if mostly accurate. > > I love GVoice for sending & receiving texts across multiple devices, some > of which aren't cellular - or wired - at all :). > *(Also have phone calls ring not just my phones, but Skype and GChat as > well ...)* > > > /TJ > From aaron.toponce at gmail.com Wed Oct 10 00:15:00 2012 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 9 Oct 2012 18:15:00 -0600 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <20121010001458.GW4872@irc.ae7.st> On Tue, Oct 09, 2012 at 03:35:37PM -0400, William Herrin wrote: > I'm looking for a way to do wireline access to send and receive > cellular phone short message service (SMS) messages. Despite all my > google-fu, I have had limited luck finding anyone that meets my needs, > so I'm hoping someone here has found the path through. My main > criteria are: > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. Avoid Google Voice. I've seen other recommendations on this, and it's horrid. Most solutions are no longer updated, there is no official API from Google, and Google changes their products regularly where stuff breaks. To suggest it as a critical production solution blows my mind. Instead, purchase a cellular USB modem with a standard plan. All 4 major carriers provide APIs to interact with the modems, and you get everything you need. They aren't cheap (something in the neighborhood of $30/month), but they work, they are reliable, and you have a committed telecom corp dedicated to keeping uptime high, and the API up-to-date. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From drohan at gmail.com Wed Oct 10 00:34:16 2012 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 10 Oct 2012 03:34:16 +0300 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: Look at TextMagic. They have an easy to work with API and the cost is minimal. If you are using it for monitoring purposes, you'll just have to figure out how to do it out of band. On Oct 9, 2012 10:37 PM, "William Herrin" wrote: > Hi Folks, > > I'm looking for a way to do wireline access to send and receive > cellular phone short message service (SMS) messages. Despite all my > google-fu, I have had limited luck finding anyone that meets my needs, > so I'm hoping someone here has found the path through. My main > criteria are: > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > and effectively I'll be sending to and receiving from phones I own. > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > move numbers between the two locations for failover purposes. > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > acceptable to my customer. > 4. Solution must reach phones on all U.S. cellular carriers. > 5. Price is a very distant fifth criteria to the preceding four. > > I can consider Internet based systems where the provider uses U.S. > based facilities and ties in to a U.S. phone network, provided that my > standards of reliability and redundancy are met by their > infrastructure. > > Alternately, I can also consider a wireless carrier that can provide > two SIM-based phones with the same phone number for sending and > receiving SMS messages. I'd put the sims in a pair of modems and > manage deduplication of the received messages in software. > > > Has anybody had any luck with this kind of requirement? Which vendors > should I talk to and who at the vendor? > > Thanks, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From johnl at iecc.com Wed Oct 10 01:10:22 2012 From: johnl at iecc.com (John Levine) Date: 10 Oct 2012 01:10:22 -0000 Subject: Wired access to SMS? In-Reply-To: Message-ID: <20121010011022.36073.qmail@joyce.lan> >Look at TextMagic. They're in the UK. You might take a look at Aerialink who are in the US: http://www.aerialink.com/gateway/options/outbound-sms/ Getting your own cellular modem may well end up being more reliable and cheaper in the long run, since you are less at the mercy of other people's software. From fohdeesha at gmail.com Mon Oct 8 12:20:34 2012 From: fohdeesha at gmail.com (Jon Sands) Date: Mon, 08 Oct 2012 08:20:34 -0400 Subject: Typical additional latency for CGN? In-Reply-To: References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> Message-ID: <5072C512.2000105@gmail.com> On 10/7/2012 9:22 PM, Jon Lewis wrote: > has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) > connections? Not here, have an SSH session open on my phone on port 22 as we speak. I'm on an android on ATT's 3G network in central indiana, if that matters. -- Jon Sands Fohdeesha Media http://fohdeesha.com/ From andre-nanog at tomt.net Mon Oct 8 21:17:40 2012 From: andre-nanog at tomt.net (Andre Tomt) Date: Mon, 08 Oct 2012 23:17:40 +0200 Subject: Typical additional latency for CGN? In-Reply-To: <20121008092709.GA32240@srv03.cluenet.de> References: <20121008092709.GA32240@srv03.cluenet.de> Message-ID: <507342F4.8090407@tomt.net> On 08. okt. 2012 11:27, Daniel Roesen wrote: > On Sun, Oct 07, 2012 at 03:18:56PM -0700, Cameron Byrne wrote: >> On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: >>> >>> Have there been studies on how much latency CGN adds to a typical >>> internet user? I'd also be interested in anecdotes. >>> >> >> Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not >> meaningfully add latency. CGN is not enough of a factor to impact happy >> eyeballs in a way that improves ipv6 use. > > Confirmed by my experience. Latency of the CGN's themselfes are not going to be significant if it is properly scaled and configured. Most of the added latency will be in the network path to it, depending on how the CGN's are deployed relative to the path that particular flow normally would go and how big your network is. A small detour within a DC is obviously not very noticable for most. However if you're skipping peering oppurtunities and such closer to the customer when using a big central CGN, that clearly becomes sub-optimal in terms of network performance. From contact at nullivex.com Tue Oct 9 21:50:46 2012 From: contact at nullivex.com (Bryan Tong) Date: Tue, 9 Oct 2012 15:50:46 -0600 Subject: Wired access to SMS? In-Reply-To: References: <5074810B.3070901@lcrcomputer.net> Message-ID: Arent most of the services now wrapped into Google for Business where you are the customer? I dont know about Google voice though. Thanks On Tue, Oct 9, 2012 at 3:47 PM, William Herrin wrote: > On Tue, Oct 9, 2012 at 5:05 PM, steve pirk [egrep] wrote: >> Have you looked at Google Voice much? I have mine set up to SMS all my >> devices, including email delivery, and can enable/disable devices as >> needed. The big benefit, is that I have an inbox full of all my old inbound >> and outbound text messages. > > Hi Steve, > > Google voice is a fine service and if they sold it with an API, I > might well buy it. As a free public service with a strictly unofficial > API, I can't seriously consider using it in my product's critical > path. I need a service whose provider is actually obligated to keep it > working to the standard of resilience typical of the rest of my > system. > > Let me put it another way: with google voice, google mail, google > search you are not the customer. You're the product. I use gmail for > my personal mail and I can live with that. For business services, I > need to be the customer. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From owen at delong.com Wed Oct 10 12:37:09 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Oct 2012 05:37:09 -0700 Subject: Typical additional latency for CGN? In-Reply-To: <5072C512.2000105@gmail.com> References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> <5072C512.2000105@gmail.com> Message-ID: The day before I left the US, it was still working on my iPad. Owen On Oct 8, 2012, at 5:20 AM, Jon Sands wrote: > On 10/7/2012 9:22 PM, Jon Lewis wrote: >> has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) connections? > > Not here, have an SSH session open on my phone on port 22 as we speak. I'm on an android on ATT's 3G network in central indiana, if that matters. > > -- > Jon Sands > Fohdeesha Media > http://fohdeesha.com/ > From jlewis at lewis.org Wed Oct 10 13:25:12 2012 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 10 Oct 2012 09:25:12 -0400 (EDT) Subject: Typical additional latency for CGN? In-Reply-To: References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> <5072C512.2000105@gmail.com> Message-ID: I just spent a few minutes looking into this again, and figured out the problem. AT&T has apparently changed the way their CGN works. I use a form of port knocking to restrict access to SSHd from "foreign" networks. It used to work fine from my phone. Now, the port knocking request from the phone and the ssh connection are being NAT'd to different public IPs, so my system is allowing ssh access to one AT&T IP, and then the ssh connection comes from a nearby but different IP. On Wed, 10 Oct 2012, Owen DeLong wrote: > The day before I left the US, it was still working on my iPad. > > Owen > > On Oct 8, 2012, at 5:20 AM, Jon Sands wrote: > >> On 10/7/2012 9:22 PM, Jon Lewis wrote: >>> has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) connections? >> >> Not here, have an SSH session open on my phone on port 22 as we speak. I'm on an android on ATT's 3G network in central indiana, if that matters. >> >> -- >> Jon Sands >> Fohdeesha Media >> http://fohdeesha.com/ >> > > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From MDikkema at postmedia.com Wed Oct 10 13:46:58 2012 From: MDikkema at postmedia.com (Dikkema, Michael (Business Technology)) Date: Wed, 10 Oct 2012 08:46:58 -0500 Subject: MPLS on 6500 VSS Message-ID: <4DD46B838E59A647A9FE326E7552F8361F20972469@WPGMSXMBX02.ca.canwest.com> Hi, all. I'm looking at deploying MPLS and MPLS VPN on a number of 6500 VSS (VS-S720) systems. Was wondering if there were any major issues to look out for specific to this platform. Thanks. From nick at foobar.org Wed Oct 10 14:24:49 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 10 Oct 2012 15:24:49 +0100 Subject: MPLS on 6500 VSS In-Reply-To: <4DD46B838E59A647A9FE326E7552F8361F20972469@WPGMSXMBX02.ca.canwest.com> References: <4DD46B838E59A647A9FE326E7552F8361F20972469@WPGMSXMBX02.ca.canwest.com> Message-ID: <50758531.3000009@foobar.org> On 10/10/2012 14:46, Dikkema, Michael (Business Technology) wrote: > I'm looking at deploying MPLS and MPLS VPN on a number of 6500 VSS > (VS-S720) systems. Was wondering if there were any major issues to look > out for specific to this platform. There may be several issues to look out for, depending on what you're trying to do. Check the cisco-nsp archives (puck.nether.net) for more details. Nick From otis at ocosa.com Wed Oct 10 14:28:33 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 10 Oct 2012 09:28:33 -0500 Subject: MPLS on 6500 VSS In-Reply-To: <4DD46B838E59A647A9FE326E7552F8361F20972469@WPGMSXMBX02.ca.canwest.com> References: <4DD46B838E59A647A9FE326E7552F8361F20972469@WPGMSXMBX02.ca.canwest.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017E6B@ocsbs.ocosa.com> Have you searched the c-nsp list? You might have better luck there IMO. http://puck.nether.net/mailman/listinfo/cisco-nsp (if not a member) https://puck.nether.net/pipermail/cisco-nsp/ (archives) I would look there first. There seems to be some discussion also on http://supportforums.cisco.com about this. Otis -----Original Message----- From: Dikkema, Michael (Business Technology) [mailto:MDikkema at postmedia.com] Sent: Wednesday, October 10, 2012 8:47 AM To: nanog at nanog.org Subject: MPLS on 6500 VSS Hi, all. I'm looking at deploying MPLS and MPLS VPN on a number of 6500 VSS (VS-S720) systems. Was wondering if there were any major issues to look out for specific to this platform. Thanks. From j at arpa.com Wed Oct 10 16:18:33 2012 From: j at arpa.com (jamie rishaw) Date: Wed, 10 Oct 2012 11:18:33 -0500 Subject: Wired access to SMS? In-Reply-To: <20121010001458.GW4872@irc.ae7.st> References: <20121010001458.GW4872@irc.ae7.st> Message-ID: On Tue, Oct 9, 2012 at 7:15 PM, Aaron Toponce @ gmail.com > wrote: > > Instead, purchase a cellular USB modem with a standard plan. All 4 major > carriers provide APIs to interact with the modems, and you get everything > you need*. They aren't cheap (something in the neighborhood of $30/month), * > but they work, they are reliable, and you have a committed telecom corp > dedicated to keeping uptime high, and the API up-to-date. > .. Just my $0.03, If his need is mission critical, and $30/mo breaks the bank .. I'd respectfully submit that there wasn't much of a mission.. :-p I do agree, tho, that an external / serial / mmmmaybe-usb gsm device is the route to pursue. I also '+1' / 'bump' the earlier suggestion that the OP (bill) look into Twilio. Their level of support/interaction/help/you-name-it sets standards I wish everyone lived by, and Twilio ease of use & reliability is second to none, or, at the least, one of a very few. -j. -- jamie rishaw // .com.arpa at j <- reverse it. ish. From bill at herrin.us Wed Oct 10 17:10:21 2012 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2012 13:10:21 -0400 Subject: Wired access to SMS? In-Reply-To: References: <20121010001458.GW4872@irc.ae7.st> Message-ID: On Wed, Oct 10, 2012 at 12:18 PM, jamie rishaw wrote: > On Tue, Oct 9, 2012 at 7:15 PM, Aaron Toponce >> Instead, purchase a cellular USB modem with a standard plan. All 4 major >> carriers provide APIs to interact with the modems, and you get everything >> you need*. They aren't cheap (something in the neighborhood of $30/month), > If his need is mission critical, and $30/mo breaks the bank .. I'd > respectfully submit that there wasn't much of a mission.. :-p > > I do agree, tho, that an external / serial / mmmmaybe-usb gsm device is > the route to pursue. Perhaps I should explain a little further: I have a system in place based on just under a dozen Multitech GSM modems in a room by a window. It works... more or less. It has no provisions for equipment or site failure. The modem breaks, that number is unavailable. The site fails, that number is unavailable. The local cell network gets jammed, the number is unavailable. That's the opposite of "high availability." So, I need to replace it with something that offers high availability for each phone number, aka "SMS long code." I realize that the phone end will still suffer all the vagaries of SMS. But on the base end I need high availability. I expect this to cost more than throwing a dozen GSM modems in a room. I won't be offended when it does. Anyway, I want to thank everybody for the suggestions, public and private. You've given me some solid leads I can pursue. I'll let you know how it turns out. Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Wed Oct 10 17:36:33 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 10 Oct 2012 10:36:33 -0700 Subject: Wired access to SMS? In-Reply-To: References: <20121010001458.GW4872@irc.ae7.st> Message-ID: <5075B221.1070304@rollernet.us> On 10/10/12 10:10 AM, William Herrin wrote: > On Wed, Oct 10, 2012 at 12:18 PM, jamie rishaw wrote: >> On Tue, Oct 9, 2012 at 7:15 PM, Aaron Toponce >>> Instead, purchase a cellular USB modem with a standard plan. All 4 major >>> carriers provide APIs to interact with the modems, and you get everything >>> you need*. They aren't cheap (something in the neighborhood of $30/month), > >> If his need is mission critical, and $30/mo breaks the bank .. I'd >> respectfully submit that there wasn't much of a mission.. :-p >> >> I do agree, tho, that an external / serial / mmmmaybe-usb gsm device is >> the route to pursue. > > Perhaps I should explain a little further: > > I have a system in place based on just under a dozen Multitech GSM > modems in a room by a window. It works... more or less. > > It has no provisions for equipment or site failure. The modem breaks, > that number is unavailable. The site fails, that number is > unavailable. The local cell network gets jammed, the number is > unavailable. That's the opposite of "high availability." > > So, I need to replace it with something that offers high availability > for each phone number, aka "SMS long code." I realize that the phone > end will still suffer all the vagaries of SMS. But on the base end I > need high availability. > > I expect this to cost more than throwing a dozen GSM modems in a room. > I won't be offended when it does. > What about finding someplace offsite and setting up a persistent PPP connection with modems (of the POTS variety) between it and home base? Put half the modems there and maybe a low power Atom server with hooks to send alerts like "connection to home hasn't come back after X redials". I do something similar by having cheap DSL with a provider I don't have any other services with to provide a outside world view of things. I have a POTS line there too that can auto-dial back home if needed. ~Seth From bill at herrin.us Wed Oct 10 17:41:00 2012 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2012 13:41:00 -0400 Subject: Wired access to SMS? In-Reply-To: <5075B221.1070304@rollernet.us> References: <20121010001458.GW4872@irc.ae7.st> <5075B221.1070304@rollernet.us> Message-ID: On Wed, Oct 10, 2012 at 1:36 PM, Seth Mattinen wrote: > On 10/10/12 10:10 AM, William Herrin wrote: >> So, I need to replace it with something that offers high availability >> for each phone number, aka "SMS long code." I realize that the phone >> end will still suffer all the vagaries of SMS. But on the base end I >> need high availability. > > What about finding someplace offsite and setting up a persistent PPP > connection with modems (of the POTS variety) between it and home base? > Put half the modems there and maybe a low power Atom server with hooks > to send alerts like "connection to home hasn't come back after X redials". To do that, I'd need a way to assign the same phone number (SMS long code) to two different modems, one at the first site, one at the second. I'd welcome a lead on a phone product or vendor who can do that for me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike.lyon at gmail.com Wed Oct 10 18:02:29 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 10 Oct 2012 11:02:29 -0700 Subject: Wired access to SMS? In-Reply-To: References: <20121010001458.GW4872@irc.ae7.st> <5075B221.1070304@rollernet.us> Message-ID: Inmarsat SMS? http://www.marlink.com/text-messaging.html -Mike On Wed, Oct 10, 2012 at 10:41 AM, William Herrin wrote: > On Wed, Oct 10, 2012 at 1:36 PM, Seth Mattinen wrote: > > On 10/10/12 10:10 AM, William Herrin wrote: > >> So, I need to replace it with something that offers high availability > >> for each phone number, aka "SMS long code." I realize that the phone > >> end will still suffer all the vagaries of SMS. But on the base end I > >> need high availability. > > > > What about finding someplace offsite and setting up a persistent PPP > > connection with modems (of the POTS variety) between it and home base? > > Put half the modems there and maybe a low power Atom server with hooks > > to send alerts like "connection to home hasn't come back after X > redials". > > To do that, I'd need a way to assign the same phone number (SMS long > code) to two different modems, one at the first site, one at the > second. I'd welcome a lead on a phone product or vendor who can do > that for me. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From richard.e.brown at dartware.com Wed Oct 10 18:51:05 2012 From: richard.e.brown at dartware.com (Richard Brown) Date: Wed, 10 Oct 2012 18:51:05 +0000 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: On Oct 10, 2012, at 2:02 PM, Bill Herrin wrote: > What about finding someplace offsite and setting up a persistent PPP > connection with modems (of the POTS variety) between it and home base? > Put half the modems there and maybe a low power Atom server with hooks > to send alerts like "connection to home hasn't come back after X redials". > > I do something similar by having cheap DSL with a provider I don't have > any other services with to provide a outside world view of things. I > have a POTS line there too that can auto-dial back home if needed. If we're looking for belt and suspenders solutions (when you lose your primary WAN connection and the cell modems are jammed up...) You could also hitch up an analog modem to a POTS line, and then let your paging software dial your cell/home number. You won't hear anything, but the CallerID will let you know that your monitoring system is *desperately* trying to get in touch :-) Rich Brown richard.e.brown at dartware.com Dartware, LLC http://www.intermapper.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289 From nathan at atlasnetworks.us Wed Oct 10 21:34:21 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 10 Oct 2012 21:34:21 +0000 Subject: Wired access to SMS? In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C2895AC1620@EX-MB-1.corp.atlasnetworks.us> > You could also hitch up an analog modem to a POTS line, and then let your paging software dial your cell/home number. > You won't hear anything, but the CallerID will let you know that your monitoring system is *desperately* trying to get in touch :-) You could take it one step further and get an FXO card and put it in a very basic asterisk server. Write a simple program which call be pinged with issue reports as an argument, then pass those arguments to festvox or other TTS application. Output to WAV, convert to GSM, generate an asterisk call file (or write an extension) that calls you on the analog line, and plays you the sound file. I've done this at several employers. It works fairly well - perhaps better than it sounds. If you can get a SIP upstream that will let you set your CID, then send the calls out that route first, and the POTS line becomes a backup - then if you ever get calls from the POTS DID, you know that you have the original problem, plus you know that the connection to the SIP gateway is down. Nathan Eisenberg From deepak at ai.net Wed Oct 10 22:15:39 2012 From: deepak at ai.net (Deepak Jain) Date: Wed, 10 Oct 2012 18:15:39 -0400 Subject: Wired access to SMS? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2895AC1620@EX-MB-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C2895AC1620@EX-MB-1.corp.atlasnetworks.us> Message-ID: <5075F38B.6030507@ai.net> On 10/10/2012 5:34 PM, Nathan Eisenberg wrote: >> You could also hitch up an analog modem to a POTS line, and then let your paging software dial your cell/home number. >> You won't hear anything, but the CallerID will let you know that your monitoring system is *desperately* trying to get in touch :-) > > You could take it one step further and get an FXO card and put it in a very basic asterisk server. Write a simple program which call be pinged with issue reports as an argument, then pass those arguments to festvox or other TTS application. Output to WAV, convert to GSM, generate an asterisk call file (or write an extension) that calls you on the analog line, and plays you the sound file. > > I've done this at several employers. It works fairly well - perhaps better than it sounds. If you can get a SIP upstream that will let you set your CID, then send the calls out that route first, and the POTS line becomes a backup - then if you ever get calls from the POTS DID, you know that you have the original problem, plus you know that the connection to the SIP gateway is down. > > Nathan Eisenberg Correct me if I'm wrong, but shouldn't it be possible to grab SMS via SS7 and feed it into a softswitch or similar like an Asterisk box? All that would be required would be a friendly SMS provider with an "SMS peering" or gateway with the network(s) you care about. I know Verizon was offering a landline VoIP phone that offered SMS long code support a while ago, but I was never sufficiently interested to examine it further. DJ From marka at isc.org Wed Oct 10 22:30:03 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 11 Oct 2012 09:30:03 +1100 Subject: Typical additional latency for CGN? In-Reply-To: Your message of "Wed, 10 Oct 2012 09:25:12 EDT." References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> <5072C512.2000105@gmail.com> Message-ID: <20121010223003.98BAA299463A@drugs.dv.isc.org> In message , Jon Lewis writ es: > I just spent a few minutes looking into this again, and figured out the > problem. AT&T has apparently changed the way their CGN works. I use a > form of port knocking to restrict access to SSHd from "foreign" networks. > It used to work fine from my phone. Now, the port knocking request from > the phone and the ssh connection are being NAT'd to different public IPs, > so my system is allowing ssh access to one AT&T IP, and then the ssh > connection comes from a nearby but different IP. Which is a badly designed CGN. I turns singly homed clients into multi-homed client where the client has no control over the source address selection. At least with real multi-homed clients they have the ability to force source addresses to match. > On Wed, 10 Oct 2012, Owen DeLong wrote: > > > The day before I left the US, it was still working on my iPad. > > > > Owen > > > > On Oct 8, 2012, at 5:20 AM, Jon Sands wrote: > > > >> On 10/7/2012 9:22 PM, Jon Lewis wrote: > >>> has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) con > nections? > >> > >> Not here, have an SSH session open on my phone on port 22 as we speak. I'm > on an android on ATT's 3G network in central indiana, if that matters. > >> > >> -- > >> Jon Sands > >> Fohdeesha Media > >> http://fohdeesha.com/ > >> > > > > > > > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Wed Oct 10 23:11:55 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Oct 2012 16:11:55 -0700 Subject: Typical additional latency for CGN? In-Reply-To: <20121010223003.98BAA299463A@drugs.dv.isc.org> References: <933EBEE8-9802-453B-8E30-F583D5C7756A@delong.com> <5072C512.2000105@gmail.com> <20121010223003.98BAA299463A@drugs.dv.isc.org> Message-ID: <961D658D-F3ED-44FE-803F-BE8B7C3C8EDD@delong.com> On Oct 10, 2012, at 3:30 PM, Mark Andrews wrote: > > In message , Jon Lewis writ > es: >> I just spent a few minutes looking into this again, and figured out the >> problem. AT&T has apparently changed the way their CGN works. I use a >> form of port knocking to restrict access to SSHd from "foreign" networks. >> It used to work fine from my phone. Now, the port knocking request from >> the phone and the ssh connection are being NAT'd to different public IPs, >> so my system is allowing ssh access to one AT&T IP, and then the ssh >> connection comes from a nearby but different IP. > > Which is a badly designed CGN. I turns singly homed clients into > multi-homed client where the client has no control over the source > address selection. At least with real multi-homed clients they have > the ability to force source addresses to match. > AT&T probably likes it for mobile, however, because it's about the easiest way possible to prevent data services from being successfully used for VOIP. Owen >> On Wed, 10 Oct 2012, Owen DeLong wrote: >> >>> The day before I left the US, it was still working on my iPad. >>> >>> Owen >>> >>> On Oct 8, 2012, at 5:20 AM, Jon Sands wrote: >>> >>>> On 10/7/2012 9:22 PM, Jon Lewis wrote: >>>>> has anyone else noticed AT&T mobile is blocking ssh (outgoing 22/tcp) con >> nections? >>>> >>>> Not here, have an SSH session open on my phone on port 22 as we speak. I'm >> on an android on ATT's 3G network in central indiana, if that matters. >>>> >>>> -- >>>> Jon Sands >>>> Fohdeesha Media >>>> http://fohdeesha.com/ >>>> >>> >>> >>> >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joly at punkcast.com Thu Oct 11 00:23:44 2012 From: joly at punkcast.com (Joly MacFie) Date: Wed, 10 Oct 2012 20:23:44 -0400 Subject: Wired access to SMS? In-Reply-To: <5689085792276961524@unknownmsgid> References: <5689085792276961524@unknownmsgid> Message-ID: More precisely http://www.twilio.com/sms j On Tue, Oct 9, 2012 at 3:37 PM, Tim M Edwards wrote: > Twillio.com > > On Oct 9, 2012, at 12:36 PM, William Herrin wrote: > > > Hi Folks, > > > > I'm looking for a way to do wireline access to send and receive > > cellular phone short message service (SMS) messages. Despite all my > > google-fu, I have had limited luck finding anyone that meets my needs, > > so I'm hoping someone here has found the path through. My main > > criteria are: > > > > > > 1. Low quantity, high reliability. I'll want a few dozen phone numbers > > and effectively I'll be sending to and receiving from phones I own. > > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > > move numbers between the two locations for failover purposes. > > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > > acceptable to my customer. > > 4. Solution must reach phones on all U.S. cellular carriers. > > 5. Price is a very distant fifth criteria to the preceding four. > > > > I can consider Internet based systems where the provider uses U.S. > > based facilities and ties in to a U.S. phone network, provided that my > > standards of reliability and redundancy are met by their > > infrastructure. > > > > Alternately, I can also consider a wireless carrier that can provide > > two SIM-based phones with the same phone number for sending and > > receiving SMS messages. I'd put the sims in a pair of modems and > > manage deduplication of the received messages in software. > > > > > > Has anybody had any luck with this kind of requirement? Which vendors > > should I talk to and who at the vendor? > > > > Thanks, > > Bill Herrin > > > > > > -- > > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > > > -- --------------------------------------------------------------- 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 tore.anderson at redpill-linpro.com Thu Oct 11 06:31:44 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 11 Oct 2012 08:31:44 +0200 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: Message-ID: <507667D0.8060404@redpill-linpro.com> * Cameron Byrne > FYI http://www.dslreports.com/forum/r27324698-LTE-access-early- > > So much for next generation technology ... Yesterday, Telenor launched LTE. So. With a green-field deployment, in their home market (supposed to be the first of their tree-digit million subscribers world-wide to get all the cool new tech), built on 3GPP specs that fully supports IPv6, already proven to work by other pioneers (^5 VzW), for which there are plenty of compatible devices (again, ^5 VzW), and plenty of compatible content (^5 ISOC, et al.), four months after World IPv6 Launch (in which they participated), and one month after their RIR ran out of IPv4 addresses...launching without IPv6 support was a perfectly natural and sensible thing for them to do, it seems. *sigh* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From swmike at swm.pp.se Thu Oct 11 06:45:43 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Oct 2012 08:45:43 +0200 (CEST) Subject: Another LTE network turns up as IPv4-only In-Reply-To: <507667D0.8060404@redpill-linpro.com> References: <507667D0.8060404@redpill-linpro.com> Message-ID: On Thu, 11 Oct 2012, Tore Anderson wrote: > So. With a green-field deployment, in their home market (supposed to be > the first of their tree-digit million subscribers world-wide to get all > the cool new tech), built on 3GPP specs that fully supports IPv6, > already proven to work by other pioneers (^5 VzW), for which there are > plenty of compatible devices (again, ^5 VzW), and plenty of compatible > content (^5 ISOC, et al.), four months after World IPv6 Launch (in which > they participated), and one month after their RIR ran out of IPv4 > addresses...launching without IPv6 support was a perfectly natural and > sensible thing for them to do, it seems. The problem I have seen is not to get IPv6/dual stack in LTE (this worked from day one), it's to get dual stack working in all the cases with bearer establishment and handover between 2G/3G and 4G. 2G/3G is "fully integrated" with each other, but LTE is still kind of separate, vendors are just now getting around to producing mobile core nodes that support all of them with a single node for each function. Would you want to get IPv6 when you're in the LTE network but lose it when you were handed over to 2G/3G. My guess is not, so I believe providers will wait until that is really done. -- Mikael Abrahamsson email: swmike at swm.pp.se From bmanning at vacation.karoshi.com Thu Oct 11 06:57:48 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 11 Oct 2012 06:57:48 +0000 Subject: Another LTE network turns up as IPv4-only In-Reply-To: <507667D0.8060404@redpill-linpro.com> References: <507667D0.8060404@redpill-linpro.com> Message-ID: <20121011065748.GA25259@vacation.karoshi.com.> https://intelligence.businessinsider.com/facebook-is-adding-over-25000-mobile-users-an-hour-2012-10 dream big.... /bill On Thu, Oct 11, 2012 at 08:31:44AM +0200, Tore Anderson wrote: > * Cameron Byrne > > > FYI http://www.dslreports.com/forum/r27324698-LTE-access-early- > > > > So much for next generation technology ... > > Yesterday, Telenor launched LTE. > > So. With a green-field deployment, in their home market (supposed to be > the first of their tree-digit million subscribers world-wide to get all > the cool new tech), built on 3GPP specs that fully supports IPv6, > already proven to work by other pioneers (^5 VzW), for which there > are plenty of compatible devices (again, ^5 VzW), and plenty of > compatible content (^5 ISOC, et al.), four months after World IPv6 > Launch (in which they participated), and one month after their RIR ran > out of IPv4 addresses...launching without IPv6 support was a perfectly > natural and sensible thing for them to do, it seems. > > *sigh* > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ From tore.anderson at redpill-linpro.com Thu Oct 11 07:04:38 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 11 Oct 2012 09:04:38 +0200 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> Message-ID: <50766F86.4010002@redpill-linpro.com> * Mikael Abrahamsson > Would you want to get IPv6 when you're in the LTE network but lose it > when you were handed over to 2G/3G. Absolutely. That some features are available only on the most advanced access technology is perfectly reasonable and to be expected, IMHO. If not, what's the point of upgrading at all? I lose my YouTube streams when I get handed over from 3G to 2G, too, for example. I can live with that. I much prefer it to YouTube not working 3G as well, even though that might very well be considered a more "consistent" user experience. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From swmike at swm.pp.se Thu Oct 11 07:44:45 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Oct 2012 09:44:45 +0200 (CEST) Subject: Another LTE network turns up as IPv4-only In-Reply-To: <50766F86.4010002@redpill-linpro.com> References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> Message-ID: On Thu, 11 Oct 2012, Tore Anderson wrote: > That some features are available only on the most advanced access > technology is perfectly reasonable and to be expected, IMHO. If not, > what's the point of upgrading at all? Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and if they happen to go over IPv6, I want them to survive. The important reason to upgrade is to get higher speeds, not to get access to new L3 tech. > I lose my YouTube streams when I get handed over from 3G to 2G, too, for > example. I can live with that. I much prefer it to YouTube not working > 3G as well, even though that might very well be considered a more > "consistent" user experience. I don't agree with you at all. I don't believe I would lose the stream when doing that handoff in our network, it might buffer some more (because EDGE is slower than HSDPA), but you wouldn't lose the stream. Consistent behaviour (apart from speed) on all networks is really important for me, and I'd imagine it is for most users as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From matthew at matthew.at Thu Oct 11 08:29:23 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 11 Oct 2012 09:29:23 +0100 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> Message-ID: <50768363.8060900@matthew.at> On 10/11/2012 8:44 AM, Mikael Abrahamsson wrote: > On Thu, 11 Oct 2012, Tore Anderson wrote: > >> That some features are available only on the most advanced access >> technology is perfectly reasonable and to be expected, IMHO. If not, >> what's the point of upgrading at all? > > Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and > if they happen to go over IPv6, I want them to survive. If your SSH sessions could survive a change in address assignment (which often happens in a handover), they could survive a change in address family assignment as well. Unfortunately, TCP - upon which ssh is built - uses the routing identifiers as the host identifiers, and so this doesn't work. > > The important reason to upgrade is to get higher speeds, not to get > access to new L3 tech. > >> I lose my YouTube streams when I get handed over from 3G to 2G, too, >> for example. I can live with that. I much prefer it to YouTube not >> working 3G as well, even though that might very well be considered a >> more "consistent" user experience. > > I don't agree with you at all. I don't believe I would lose the stream > when doing that handoff in our network, it might buffer some more > (because EDGE is slower than HSDPA), but you wouldn't lose the stream. But the stream would almost certainly be coming to a newly assigned IP address (and once you're doing that, who cares if the family changes too?) > > Consistent behaviour (apart from speed) on all networks is really > important for me, and I'd imagine it is for most users as well. > The *only* inconsistency would be when you're accessing the IPv6-only part of the Internet, of which there's currently none that consumers care about. Matthew Kaufman From swmike at swm.pp.se Thu Oct 11 08:41:46 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Oct 2012 10:41:46 +0200 (CEST) Subject: Another LTE network turns up as IPv4-only In-Reply-To: <50768363.8060900@matthew.at> References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768363.8060900@matthew.at> Message-ID: On Thu, 11 Oct 2012, Matthew Kaufman wrote: > If your SSH sessions could survive a change in address assignment (which > often happens in a handover), they could survive a change in address > family assignment as well. Why would there be an address change in a handover? That is definitely not expected behaviour. > But the stream would almost certainly be coming to a newly assigned IP > address? Why do you believe that address changes in handover? It's an integral part of 3GPP standard that your existing bearer is used for handover, so your address shouldn't change. If it changes then it means the handover didn't work as designed, probably due to some radio related problem. If the address changed, then it means the bearer was torn down and a new bearer was initiated. This is definitely not expected behaviour. We have plenty of customers with bearers that are up for tens of days in a row. > The *only* inconsistency would be when you're accessing the IPv6-only > part of the Internet, of which there's currently none that consumers > care about. If a user is accessing a stream from an IPv6 enabled CDN that stream shouldn't be reset just because a handover happened. -- Mikael Abrahamsson email: swmike at swm.pp.se From contact at nullivex.com Thu Oct 11 08:55:11 2012 From: contact at nullivex.com (Bryan Tong) Date: Thu, 11 Oct 2012 02:55:11 -0600 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768363.8060900@matthew.at> Message-ID: > Why do you believe that address changes in handover? It's an integral part > of 3GPP standard that your existing bearer is used for handover, so your > address shouldn't change. If it changes then it means the handover didn't > work as designed, probably due to some radio related problem. If the address > changed, then it means the bearer was torn down and a new bearer was > initiated. This is definitely not expected behaviour. We have plenty of > customers with bearers that are up for tens of days in a row. For that to be true wouldnt support for IPv6 need to be in all generations of networks. With that standard in place there can not be new protocols without retrofitting. For a user to switch from 6 to 4 would require and address change however that address change would be reliant on DNS which would be out of the scope of network grade support. On Thu, Oct 11, 2012 at 2:41 AM, Mikael Abrahamsson wrote: > On Thu, 11 Oct 2012, Matthew Kaufman wrote: > >> If your SSH sessions could survive a change in address assignment (which >> often happens in a handover), they could survive a change in address family >> assignment as well. > > > Why would there be an address change in a handover? That is definitely not > expected behaviour. > >> But the stream would almost certainly be coming to a newly assigned IP >> address? > > > Why do you believe that address changes in handover? It's an integral part > of 3GPP standard that your existing bearer is used for handover, so your > address shouldn't change. If it changes then it means the handover didn't > work as designed, probably due to some radio related problem. If the address > changed, then it means the bearer was torn down and a new bearer was > initiated. This is definitely not expected behaviour. We have plenty of > customers with bearers that are up for tens of days in a row. > > >> The *only* inconsistency would be when you're accessing the IPv6-only part >> of the Internet, of which there's currently none that consumers care about. > > > If a user is accessing a stream from an IPv6 enabled CDN that stream > shouldn't be reset just because a handover happened. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From tore.anderson at redpill-linpro.com Thu Oct 11 09:09:35 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 11 Oct 2012 11:09:35 +0200 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> Message-ID: <50768CCF.3090003@redpill-linpro.com> * Mikael Abrahamsson > On Thu, 11 Oct 2012, Tore Anderson wrote: > >> That some features are available only on the most advanced access >> technology is perfectly reasonable and to be expected, IMHO. If not, >> what's the point of upgrading at all? > > Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and if > they happen to go over IPv6, I want them to survive. In my experience, long-lived sessions are unreliable when you're on the move anyway. Go into an elevator? Sessions drop. Subway heads into a tunnel? Sessions drop. Get in range of a known WiFi network? Sessions drop. If you want to make an app for mobile, you better be able to recover. So for me, this is hardly a concern. Still, I'll grant you that you that you and I might have different priorities here. I think this is a really poor excuse for not supporting IPv6 and IPv4v6 in any case. Unless I'm gravely misinformed on how 3GPP mobile networks work, there is absolutely no reason why you cannot on LTE simultaneously support IPv4, IPv6, and IPv4v6. That the LTE network additionally supports IPv6/IPv4v6 does not *in any way* prevent you from sticking to IPv4 in all cases and enjoying the exact same session mobility between 2G/3G/4G as you can if the LTE network only supports IPv4. The session mobility problem will not go away completely by upgrading the 2G/3G part of the network, too. As I understand it, there's no shortage of devices on the market that only supports IPv6 on LTE, but not on 3G. Apple's iPhones and iPads, for example. So while it won't be the network's fault, it doesn't really matter - from the end users's point of view, the exact same thing will happen. Besides, the LTE network is being touted as a potential replacement for wired broadband. In that use case, the end user isn't likely to be mobile at all - presumably he'll have some CPE sitting in his window sill within LTE coverage 100% of the time. So no session mobility issues, and all the potential to be provisioned with IPv6 access. But no. > The important reason to upgrade is to get higher speeds, not to get > access to new L3 tech. Missed opportunity if you ask me. We could have had both. >> I lose my YouTube streams when I get handed over from 3G to 2G, too, >> for example. I can live with that. I much prefer it to YouTube not >> working 3G as well, even though that might very well be considered a >> more "consistent" user experience. > > I don't agree with you at all. I don't believe I would lose the stream > when doing that handoff in our network, it might buffer some more > (because EDGE is slower than HSDPA), but you wouldn't lose the stream. I'm not watching a YouTube stream to see a still frame with a "buffering..." animation on top, so if I roam into 2G while watching something, I'll be putting my phone away anyway. Whether or not I actually lose the TCP connection is besides the point, the application is useless anyway. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From swmike at swm.pp.se Thu Oct 11 09:42:28 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Oct 2012 11:42:28 +0200 (CEST) Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768363.8060900@matthew.at> Message-ID: On Thu, 11 Oct 2012, Bryan Tong wrote: >> Why do you believe that address changes in handover? It's an integral part >> of 3GPP standard that your existing bearer is used for handover, so your >> address shouldn't change. If it changes then it means the handover didn't >> work as designed, probably due to some radio related problem. If the address >> changed, then it means the bearer was torn down and a new bearer was >> initiated. This is definitely not expected behaviour. We have plenty of >> customers with bearers that are up for tens of days in a row. > > For that to be true wouldnt support for IPv6 need to be in all > generations of networks. With that standard in place there can not be > new protocols without retrofitting. For a user to switch from 6 to 4 > would require and address change however that address change would be > reliant on DNS which would be out of the scope of network grade > support. The goal is to have dual stack in all networks. Single stack IPv6 has worked for a long time in 2G/3G/4G (I did first trials 2 years ago, it's a non-brainer). It's the support for a dual stack bearer that is problematic. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Thu Oct 11 09:49:11 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Oct 2012 11:49:11 +0200 (CEST) Subject: Another LTE network turns up as IPv4-only In-Reply-To: <50768CCF.3090003@redpill-linpro.com> References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768CCF.3090003@redpill-linpro.com> Message-ID: On Thu, 11 Oct 2012, Tore Anderson wrote: > * Mikael Abrahamsson > >> On Thu, 11 Oct 2012, Tore Anderson wrote: >> >>> That some features are available only on the most advanced access >>> technology is perfectly reasonable and to be expected, IMHO. If not, >>> what's the point of upgrading at all? >> >> Uh, whut? I expect my ssh sessions to survive a 4G->3G handover, and if >> they happen to go over IPv6, I want them to survive. > > In my experience, long-lived sessions are unreliable when you're on the > move anyway. Go into an elevator? Sessions drop. Subway heads into a > tunnel? Sessions drop. I guess you and me have radically different experience of mobile phone networks and how well they work. > I think this is a really poor excuse for not supporting IPv6 and IPv4v6 > in any case. Unless I'm gravely misinformed on how 3GPP mobile networks > work, there is absolutely no reason why you cannot on LTE simultaneously > support IPv4, IPv6, and IPv4v6. That the LTE network additionally > supports IPv6/IPv4v6 does not *in any way* prevent you from sticking to > IPv4 in all cases and enjoying the exact same session mobility between > 2G/3G/4G as you can if the LTE network only supports IPv4. IPv4v6 on LTE is a no-brainer, I did first tests with that 1.5-2 years ago. IPv6 only on 2G/3G/4G also works well. Not that many devices with GA firmware supports this unfortunately. > The session mobility problem will not go away completely by upgrading > the 2G/3G part of the network, too. As I understand it, there's no > shortage of devices on the market that only supports IPv6 on LTE, but > not on 3G. Apple's iPhones and iPads, for example. So while it won't be > the network's fault, it doesn't really matter - from the end users's > point of view, the exact same thing will happen. Well, with the current end user device situation, focus is on usb dongles. They seem to support all combinations just fine. > Besides, the LTE network is being touted as a potential replacement for > wired broadband. In that use case, the end user isn't likely to be > mobile at all - presumably he'll have some CPE sitting in his window > sill within LTE coverage 100% of the time. So no session mobility > issues, and all the potential to be provisioned with IPv6 access. But > no. Sure. But now you will probably have a 4G router with NAT44, with no IPv6 support at all. I'd gladly take hints of devices with proper IPv4v6 support in this area. >> The important reason to upgrade is to get higher speeds, not to get >> access to new L3 tech. > > Missed opportunity if you ask me. We could have had both. Yes we could, and we will. Just because someone isn't doing it *now* doesn't mean it won't be done in the not so distant future. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore.anderson at redpill-linpro.com Thu Oct 11 10:38:14 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 11 Oct 2012 12:38:14 +0200 Subject: Another LTE network turns up as IPv4-only In-Reply-To: References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768CCF.3090003@redpill-linpro.com> Message-ID: <5076A196.20600@redpill-linpro.com> * Mikael Abrahamsson >> In my experience, long-lived sessions are unreliable when you're on the >> move anyway. Go into an elevator? Sessions drop. Subway heads into a >> tunnel? Sessions drop. > > I guess you and me have radically different experience of mobile phone > networks and how well they work. Maybe. Welcome to Oslo. :-) >> I think this is a really poor excuse for not supporting IPv6 and >> IPv4v6 in any case. Unless I'm gravely misinformed on how 3GPP mobile >> networks work, there is absolutely no reason why you cannot on LTE >> simultaneously support IPv4, IPv6, and IPv4v6. That the LTE network >> additionally supports IPv6/IPv4v6 does not *in any way* prevent you >> from sticking to IPv4 in all cases and enjoying the exact same session >> mobility between 2G/3G/4G as you can if the LTE network only supports >> IPv4. > > IPv4v6 on LTE is a no-brainer, ...and that is *precisely* why it's so disappointing to see Telenor not supporting it from day one. >> Besides, the LTE network is being touted as a potential replacement >> for wired broadband. In that use case, the end user isn't likely to be >> mobile at all - presumably he'll have some CPE sitting in his window >> sill within LTE coverage 100% of the time. So no session mobility >> issues, and all the potential to be provisioned with IPv6 access. But no. > > Sure. But now you will probably have a 4G router with NAT44, with no > IPv6 support at all. I'd gladly take hints of devices with proper IPv4v6 > support in this area. I don't know of any 4G routers at all, but what I do know is that any 4G router with NAT44 and no IPv6 support would work just fine in an LTE network that also supported IPv6/IPv4v6. What I also do know is that if you do manage to get your hands on a dual-stack capable router (or any other mobile device really), its IPv6 capabilities will *not* work on an LTE network with no IPv6/IPv4v6 bearer support. >>> The important reason to upgrade is to get higher speeds, not to get >>> access to new L3 tech. >> >> Missed opportunity if you ask me. We could have had both. > > Yes we could, and we will. Just because someone isn't doing it *now* > doesn't mean it won't be done in the not so distant future. We could have had it available on LTE *now* and in a not so distant future on 2G/3G. Doing it incrementally like that would not break any current IPv4-only stuff, so I don't understand how it's problematic. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From j at arpa.com Thu Oct 11 11:14:41 2012 From: j at arpa.com (jamie rishaw) Date: Thu, 11 Oct 2012 06:14:41 -0500 Subject: Wired access to SMS? In-Reply-To: <20121010001458.GW4872@irc.ae7.st> References: <20121010001458.GW4872@irc.ae7.st> Message-ID: On Tue, Oct 9, 2012 at 7:15 PM, Aaron Toponce wrote: > > Instead, purchase a cellular USB modem with a standard plan. All 4 major > carriers provide APIs to interact with the modems, and you get everything > you need*. They aren't cheap (something in the neighborhood of $30/month), * > but they work, they are reliable, and you have a committed telecom corp > dedicated to keeping uptime high, and the API up-to-date. > .. Just my $0.03, If his need is mission critical, and $30/mo breaks the bank .. I'd respectfully submit that there wasn't much of a mission.. :-p I do agree, tho, that an external / serial / mmmmaybe-usb gsm device is the route to pursue. I also '+1' / 'bump' the earlier suggestion that the OP (bill) look into Twilio. Their level of support/interaction/help/you-name-it sets standards I wish everyone lived by, and Twilio ease of use & reliability is second to none, or, at the least, one of a very few. -- jamie rishaw // .com.arpa at j <- reverse it. ish. From rs at seastrom.com Thu Oct 11 11:38:44 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 11 Oct 2012 07:38:44 -0400 Subject: Another LTE network turns up as IPv4-only In-Reply-To: <20121011065748.GA25259@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Thu, 11 Oct 2012 06:57:48 +0000") References: <507667D0.8060404@redpill-linpro.com> <20121011065748.GA25259@vacation.karoshi.com.> Message-ID: <86bog9grwb.fsf@seastrom.com> Subscription only, $199/year (special introductory offer, normally $499!). Try it free for two weeks but only if you cough up info. How about a summary for those of us who are disinclined to do either? -r bmanning at vacation.karoshi.com writes: > https://intelligence.businessinsider.com/facebook-is-adding-over-25000-mobile-users-an-hour-2012-10 > > dream big.... > > /bill > > On Thu, Oct 11, 2012 at 08:31:44AM +0200, Tore Anderson wrote: >> * Cameron Byrne >> >> > FYI http://www.dslreports.com/forum/r27324698-LTE-access-early- >> > >> > So much for next generation technology ... >> >> Yesterday, Telenor launched LTE. >> >> So. With a green-field deployment, in their home market (supposed to be >> the first of their tree-digit million subscribers world-wide to get all >> the cool new tech), built on 3GPP specs that fully supports IPv6, >> already proven to work by other pioneers (^5 VzW), for which there >> are plenty of compatible devices (again, ^5 VzW), and plenty of >> compatible content (^5 ISOC, et al.), four months after World IPv6 >> Launch (in which they participated), and one month after their RIR ran >> out of IPv4 addresses...launching without IPv6 support was a perfectly >> natural and sensible thing for them to do, it seems. >> >> *sigh* >> >> -- >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com/ From joakim at aronius.se Thu Oct 11 11:49:55 2012 From: joakim at aronius.se (Joakim Aronius) Date: Thu, 11 Oct 2012 13:49:55 +0200 Subject: Another LTE network turns up as IPv4-only In-Reply-To: <5076A196.20600@redpill-linpro.com> References: <507667D0.8060404@redpill-linpro.com> <50766F86.4010002@redpill-linpro.com> <50768CCF.3090003@redpill-linpro.com> <5076A196.20600@redpill-linpro.com> Message-ID: <20121011114955.GB14216@nike.aronius.se> * Tore Anderson (tore.anderson at redpill-linpro.com) wrote: > * Mikael Abrahamsson > > >> In my experience, long-lived sessions are unreliable when you're on the > >> move anyway. Go into an elevator? Sessions drop. Subway heads into a > >> tunnel? Sessions drop. > > > > I guess you and me have radically different experience of mobile phone > > networks and how well they work. > > Maybe. Welcome to Oslo. :-) But then, if I remember correctly, Telenor choose to go all-in with one of the Chinese vendors.. I am really interested to see how that plays out. /Joakim From repstein at hostleasing.net Thu Oct 11 12:12:27 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Thu, 11 Oct 2012 08:12:27 -0400 Subject: [NANOG-announce] Seeking NANOG Communications Committee candidates for upcoming elections and my farewell Message-ID: Greetings NANOG friends and colleagues! This month, elections will take place at NANOG 56 in Dallas, TX. There are currently two open positions available on the NANOG Communications Committee for the upcoming term. Some brief information about the Committee and what we are seeking: The Communications Committee will consist of at least three members selected by the Board of Directors. Members of the Communications Committee may not serve concurrently on the Board of Directors. The chairperson of the Communications Committee will serve ex officio in a non-voting role on the Board of Directors, in order to facilitate communication between the two groups. One of the primary functions of Communications Committee is the maintenance of a community mailing list (the NANOG operators list). The Communications Committee will be responsible for the administration and minimal moderation of the list. The Board of Directors will select the new Communications Committee members after the election in October. Two positions are to be filled. The main NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating as a member of the Communications Committee gives you the opportunity to make a noticeable contribution. All candidates will be asked to complete a questionnaire about their qualifications, and to submit a Declaration of Candidacy (DoC), which is available at https://www.nanog.org/governance/elections/2012elections/2012_Declaration_of _Candidacy.docx. Communications Committee Member Responsibilities may be viewed at http://www.nanog.org/governance/CC_Member.pdf. If you have any further questions, please feel free to reach out to me directly as well. Personally, I will not be able to run again as I have now served two terms (four years) on the Committee and will be termed out. It has been a pleasure serving the members of NANOG and the Board of Directors during these last four years, from when I first started on the Mailing List Committee and watched over the transformation into what is now the Communications Committee. I'd like to thank the NANOG community for giving me this opportunity as it has certainly been an enjoyable experience. I hope to serve the community again in the future. Regards, Randy Epstein Chair, NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From randy at psg.com Thu Oct 11 14:22:54 2012 From: randy at psg.com (Randy Bush) Date: Thu, 11 Oct 2012 07:22:54 -0700 Subject: logistics ml? Message-ID: so is there a meeting logistics ml for attendees (as there is for ietf)? i was asked when i registered, but have seen nothing. e.g. i am scheduled to land dfw on sunday 14:00ish and want to ride share into town. randy From j at arpa.com Thu Oct 11 14:56:25 2012 From: j at arpa.com (jamie rishaw) Date: Thu, 11 Oct 2012 09:56:25 -0500 Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. Message-ID: +++ ATH0 http://goo.gl/EdN3C [SealandGov.org] also, http://www.guardian.co.uk/uk/2012/oct/10/prince-sealand-dies -j -- "sharp, dry wit and brash in his dealings with contestants." - Forbes /* - teh jamie. ; uri -> http://about.me/jgr */ California Voter? Vote YES on Prop 34. http://YesOn34.org/ From tknchris at gmail.com Thu Oct 11 15:12:07 2012 From: tknchris at gmail.com (chris) Date: Thu, 11 Oct 2012 11:12:07 -0400 Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. In-Reply-To: References: Message-ID: Last I heard sealand was defunct I remember the hosting havenco went dark I thought sealand shutdown too On Oct 11, 2012 10:59 AM, "jamie rishaw" wrote: > +++ > ATH0 > > http://goo.gl/EdN3C [SealandGov.org] > also, > http://www.guardian.co.uk/uk/2012/oct/10/prince-sealand-dies > > -j > -- > "sharp, dry wit and brash in his dealings with contestants." - Forbes > /* - teh jamie. ; uri -> http://about.me/jgr */ > > California Voter? Vote YES on Prop 34. http://YesOn34.org/ > From nanog at hostleasing.net Thu Oct 11 15:16:16 2012 From: nanog at hostleasing.net (Randy Epstein) Date: Thu, 11 Oct 2012 11:16:16 -0400 Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. In-Reply-To: Message-ID: As a Lord of Sealand, I can assure you Sealand is not defunct. :) Randy On 10/11/12 11:12 AM, "chris" wrote: >Last I heard sealand was defunct I remember the hosting havenco went dark >I >thought sealand shutdown too >On Oct 11, 2012 10:59 AM, "jamie rishaw" wrote: > >> +++ >> ATH0 >> >> http://goo.gl/EdN3C [SealandGov.org] >> also, >> http://www.guardian.co.uk/uk/2012/oct/10/prince-sealand-dies >> >> -j >> -- >> "sharp, dry wit and brash in his dealings with contestants." - Forbes >> /* - teh jamie. ; uri -> http://about.me/jgr */ >> >> California Voter? Vote YES on Prop 34. http://YesOn34.org/ >> From ryan at u13.net Thu Oct 11 17:13:18 2012 From: ryan at u13.net (Ryan Rawdon) Date: Thu, 11 Oct 2012 12:13:18 -0500 Subject: Verizon's New Repair Method: Plastic Garbage Bags In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0863F84A3A@mailserver2007.nyigc.globe> References: <616B4ECE1290D441AD56124FEBB03D0863F84A3A@mailserver2007.nyigc.globe> Message-ID: <13FF94D0-5590-45A2-A172-A8C4615E8DF4@u13.net> On Aug 20, 2012, at 2:09 PM, Eric Wieling wrote: > For a while we have had a customer with some lines which go down every time it rains. We put in the trouble ticket, a couple of days later Verizon says the issue is resolved...until the next time it rains. > > The customer sent us some pictures today of the pole outside their office. The repair appears to be wrapping some plastic bags around something up on the pole. Here is link to the pictures the customer sent us, in case anyone in the mood for a good scare. > > http://rock.nyigc.net/verizon/ > > > I was just walking home to see similar craftsmanship (garbage bags and all) on two poles behind our new apartment. I believe this is AT&T territory in Chicago Pole 1 - there is literally a rat/squirrel/bird nest behind the wiring: https://lh6.googleusercontent.com/-KqNM2R3MOnQ/UHb7Sk3FPmI/AAAAAAAAG84/XVDEXZTdCWo/s1126/IMG_20121011_114845.jpg https://lh5.googleusercontent.com/-Nwe3xErIU4o/UHb7Su66QLI/AAAAAAAAG84/fOl6fzEy1lM/s1126/IMG_20121011_114848.jpg https://lh5.googleusercontent.com/-sDjLkDdDt9w/UHb7SuQq-jI/AAAAAAAAG84/RAUtBJUeENE/s1126/IMG_20121011_114855.jpg Pole 2 (not quite as bad): https://lh6.googleusercontent.com/-wONWhhi4q9c/UHb7SrnX0ZI/AAAAAAAAG84/XcgxT9hDvvw/s1126/IMG_20121011_114926.jpg From joly at punkcast.com Thu Oct 11 18:08:37 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 11 Oct 2012 14:08:37 -0400 Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. In-Reply-To: References: Message-ID: James Grimmelmann's recent write up is worth reading http://works.bepress.com/cgi/viewcontent.cgi?article=1035&context=james_grimmelmann j On Thu, Oct 11, 2012 at 11:16 AM, Randy Epstein wrote: > As a Lord of Sealand, I can assure you Sealand is not defunct. :) > > Randy > > On 10/11/12 11:12 AM, "chris" wrote: > > >Last I heard sealand was defunct I remember the hosting havenco went dark > >I > >thought sealand shutdown too > >On Oct 11, 2012 10:59 AM, "jamie rishaw" wrote: > > > >> +++ > >> ATH0 > >> > >> http://goo.gl/EdN3C [SealandGov.org] > >> also, > >> http://www.guardian.co.uk/uk/2012/oct/10/prince-sealand-dies > >> > >> -j > >> -- > >> "sharp, dry wit and brash in his dealings with contestants." - Forbes > >> /* - teh jamie. ; uri -> http://about.me/jgr */ > >> > >> California Voter? Vote YES on Prop 34. http://YesOn34.org/ > >> > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From bill at herrin.us Thu Oct 11 18:12:43 2012 From: bill at herrin.us (William Herrin) Date: Thu, 11 Oct 2012 14:12:43 -0400 Subject: Verizon's New Repair Method: Plastic Garbage Bags In-Reply-To: <13FF94D0-5590-45A2-A172-A8C4615E8DF4@u13.net> References: <616B4ECE1290D441AD56124FEBB03D0863F84A3A@mailserver2007.nyigc.globe> <13FF94D0-5590-45A2-A172-A8C4615E8DF4@u13.net> Message-ID: On Thu, Oct 11, 2012 at 1:13 PM, Ryan Rawdon wrote: > I was just walking home to see similar craftsmanship (garbage > bags and all) on two poles behind our new apartment. I believe > this is AT&T territory in Chicago Solution: http://tinyurl.com/9ppty9j From gary.buhrmaster at gmail.com Thu Oct 11 18:49:32 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 11 Oct 2012 11:49:32 -0700 Subject: Verizon's New Repair Method: Plastic Garbage Bags In-Reply-To: References: <616B4ECE1290D441AD56124FEBB03D0863F84A3A@mailserver2007.nyigc.globe> <13FF94D0-5590-45A2-A172-A8C4615E8DF4@u13.net> Message-ID: On Thu, Oct 11, 2012 at 11:12 AM, William Herrin wrote: > > Solution: http://tinyurl.com/9ppty9j > Not a Stihl? (Steps back to see if anyone takes the bait....) Gary From jra at baylink.com Thu Oct 11 19:19:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Oct 2012 15:19:08 -0400 (EDT) Subject: Verizon's New Repair Method: Plastic Garbage Bags In-Reply-To: <13FF94D0-5590-45A2-A172-A8C4615E8DF4@u13.net> Message-ID: <17784835.30094.1349983148091.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ryan Rawdon" > On Aug 20, 2012, at 2:09 PM, Eric Wieling wrote: > > For a while we have had a customer with some lines which go down > > every time it rains. We put in the trouble ticket, a couple of days > > later Verizon says the issue is resolved...until the next time it > > rains. > > > > The customer sent us some pictures today of the pole outside their > > office. The repair appears to be wrapping some plastic bags around > > something up on the pole. Here is link to the pictures the customer > > sent us, in case anyone in the mood for a good scare. > > > > http://rock.nyigc.net/verizon/ > > I was just walking home to see similar craftsmanship (garbage bags and > all) on two poles behind our new apartment. I believe this is AT&T > territory in Chicago This isn't news in GTE territory, at least; I've seen them use contractor garbage bags -- or something akin to them -- and tie-wraps, to close broken pedestals, and occasionally aerial closures, for at least 30 years; GTE was Cut-To-Clear all the way back to the 80s, and maybe into the 70s. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From telmnstr at 757.org Thu Oct 11 19:59:08 2012 From: telmnstr at 757.org (telmnstr at 757.org) Date: Thu, 11 Oct 2012 15:59:08 -0400 (EDT) Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. In-Reply-To: References: Message-ID: > James Grimmelmann's recent write up is worth reading > http://works.bepress.com/cgi/viewcontent.cgi?article=1035&context=james_grimmelmann > j Octal gave a talk at Defcon or HOPE a few years in a row about Sealand. The last one he spilled the beans on how bad Sealand did. Managerial and customer base wise. IIRC for months the entire internet connection was done over a cell phone at 9600bps or some such. He went into some details about difficulties of the idea (banks won't accept you.) One of the most memorable talks I've seen. - Ethan O'Toole From jrhett at netconsonance.com Thu Oct 11 21:02:17 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Oct 2012 14:02:17 -0700 Subject: Is a /48 still the smallest thing you can route independently? Message-ID: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? Is this likely to change in the immediate future, or do I need to ask for a /44? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jeroen at unfix.org Thu Oct 11 21:17:40 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Oct 2012 23:17:40 +0200 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: <50773774.9080807@unfix.org> On 2012-10-11 23:02 , Jo Rhett wrote: > I've finally convinced $DAYJOB to deploy IPv6. Justification for the > IP space is easy, however the truth is that a /64 is more than we > need in all locations. However the last I heard was that you can't > effectively announce anything smaller than a /48. Is this still > true? > > Is this likely to change in the immediate future, or do I need to ask > for a /44? A /64 is for a single link (broadcast domain, though with IPv6 multicast domain is more appropriate). A /48 (or /56 for end-users for some of the RIRs) is for a single end-site ("a different administrative domain and/or a different physical location"). If you thus have 5 end-sites, you should have room for 5 /48s and thus a /47 is what you can justify. If you though are not able to do transit / routing between those sites as they are not connected one might want to get separate PI /48s for them. But likely if you are in that camp, just asking for address space, that you can use stably for a long time, from your network provider who provides you connectivity is a better way to go. Greets, Jeroen From surfer at mauigateway.com Thu Oct 11 21:25:16 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 11 Oct 2012 14:25:16 -0700 Subject: Is a /48 still the smallest thing you can route independently? Message-ID: <20121011142516.2F4CF0F4@resin11.mta.everyone.net> --- jrhett at netconsonance.com wrote: From: Jo Rhett I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? Is this likely to change in the immediate future, or do I need to ask for a /44? ---------------------------------------------------- A /48 is 65536 /64s and a /44 is 16x65536 /64s. If you only need one subnet (1 subnet = 1 /64), why would you try to get 16x65536 subnets, rather than the 65536 you have in the /48? scott From rcarpen at network1.net Thu Oct 11 21:28:37 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 11 Oct 2012 17:28:37 -0400 (EDT) Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <20121011142516.2F4CF0F4@resin11.mta.everyone.net> Message-ID: <656144913.331763.1349990917569.JavaMail.root@network1.net> > --- jrhett at netconsonance.com wrote: > From: Jo Rhett > > I've finally convinced $DAYJOB to deploy IPv6. Justification for the > IP space is easy, however the truth is that a /64 is more than we > need in all locations. However the last I heard was that you can't > effectively announce anything smaller than a /48. Is this still > true? > > Is this likely to change in the immediate future, or do I need to ask > for a /44? > ---------------------------------------------------- > > > A /48 is 65536 /64s and a /44 is 16x65536 /64s. If you > only need one subnet (1 subnet = 1 /64), why would you > try to get 16x65536 subnets, rather than the 65536 you > have in the /48? > > scott He said it was for multiple sites. Per ARIN policy, the next biggest chunk from a /48 is a /44, so a /44 is what should be asked for. It is perfectly justifiable if you have more than 1 site. I would not expect anything smaller than a /48 to be allowed in BGP. A bonus would be that a /44 currently costs the same as a /48 for an enduser, so there really is no drawback from getting the /44, and having enough space to not have to worry about it in the future. -Randy From jrhett at netconsonance.com Thu Oct 11 21:31:13 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Oct 2012 14:31:13 -0700 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <50773774.9080807@unfix.org> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> <50773774.9080807@unfix.org> Message-ID: First: > But likely if you are in that camp, just asking for address space, > that you can use stably for a long time, from your network provider who > provides you connectivity is a better way to go. Um, sorry I figured by the fact that I was posting on Nanog the context was clear, but I've forgotten how Nanog is now a go-to source for home network too :( The context was for what Nanog was originally intended for: We are provider-independent and peering around the world. On Oct 11, 2012, at 2:17 PM, Jeroen Massar wrote: > A /64 is for a single link ?(snip)... A /48 (or /56 for end-users for some of the RIRs) is for a single end-site Sorry, I wasn't looking for the breakdown of expected usage. I know those maps. What I was asking was whether you can PI-route a /56 or anything less than a /48 today. It's "nice" to have a few dozen of the entire Internet for each site, but totally unnecessary. > If you thus have 5 end-sites, you should have room for 5 /48s and thus a > /47 is what you can justify. Really? One bit can flip that many ways? ;-) I assume you mean /45, and apparently ARIN's recommended size is /44 anyway. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Thu Oct 11 21:33:40 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Oct 2012 14:33:40 -0700 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <656144913.331763.1349990917569.JavaMail.root@network1.net> References: <656144913.331763.1349990917569.JavaMail.root@network1.net> Message-ID: <063217D1-6FAC-4AEA-ABF8-28DB35959402@netconsonance.com> On Oct 11, 2012, at 2:28 PM, Randy Carpenter wrote: > so there really is no drawback from getting the /44, and having enough space to not have to worry about it in the future. It's only a worry if you can only route /48s, which was my question. And seriously, we're going to be banging around in the emptiness as compared to our IPv4 allocations. :) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From bill at herrin.us Thu Oct 11 21:33:42 2012 From: bill at herrin.us (William Herrin) Date: Thu, 11 Oct 2012 17:33:42 -0400 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: On Thu, Oct 11, 2012 at 5:02 PM, Jo Rhett wrote: > I've finally convinced $DAYJOB to deploy IPv6. Justification for > the IP space is easy, however the truth is that a /64 is more > than we need in all locations. However the last I heard was that > you can't effectively announce anything smaller than a /48. > Is this still true? Hi Jo, The short answer to your question is: /48 is the longest prefix from a direct RIR assignment that everyone currently accepts via BGP. /32 is the longest prefix from an ISP allocation that everyone currently accepts via BGP. As with IPv4 /24's, some folks accept longer prefixes. Not everyone. > Is this likely to change in the immediate future, or do I need to ask for a /44? You need to ask for a /44. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Thu Oct 11 21:34:39 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 11 Oct 2012 21:34:39 +0000 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: <20121011213439.GA2621@vacation.karoshi.com.> one of the downsides to v6 is the huge amnt of space the folks expect you to announce. lots of space to do nefarious things. that said. if you select your peers carefully and don't mind a bit of hand crafting, you can /96 and even /112 that said, get a /32 and assign/announce /48s... /bill On Thu, Oct 11, 2012 at 02:02:17PM -0700, Jo Rhett wrote: > I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? > > Is this likely to change in the immediate future, or do I need to ask for a /44? > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet projects. > > > From surfer at mauigateway.com Thu Oct 11 22:09:59 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 11 Oct 2012 15:09:59 -0700 Subject: Is a /48 still the smallest thing you can route independently? Message-ID: <20121011150959.2F4CCF87@resin11.mta.everyone.net> --- rcarpen at network1.net wrote: From: Randy Carpenter > --- jrhett at netconsonance.com wrote: > From: Jo Rhett > I've finally convinced $DAYJOB to deploy IPv6. Justification for the > IP space is easy, however the truth is that a /64 is more than we > need in all locations. However the last I heard was that you can't > effectively announce anything smaller than a /48. Is this still > true? > > Is this likely to change in the immediate future, or do I need to ask > for a /44? > ---------------------------------------------------- > A /48 is 65536 /64s and a /44 is 16x65536 /64s. If you > only need one subnet (1 subnet = 1 /64), why would you > try to get 16x65536 subnets, rather than the 65536 you > have in the /48? ------------------------------------------------------- He said it was for multiple sites. --------------------------------------------------- DOH! Note to self: focus on the outage and don't respond to NANOG while troubleshooting. ;-) scott From rcarpen at network1.net Thu Oct 11 22:06:09 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 11 Oct 2012 18:06:09 -0400 (EDT) Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <063217D1-6FAC-4AEA-ABF8-28DB35959402@netconsonance.com> Message-ID: <298704693.331779.1349993169198.JavaMail.root@network1.net> ----- Original Message ----- > > > On Oct 11, 2012, at 2:28 PM, Randy Carpenter wrote: > > > so there really is no drawback from getting the /44, and having > enough space to not have to worry about it in the future. > > > It's only a worry if you can only route /48s, which was my question. > And seriously, we're going to be banging around in the emptiness as > compared to our IPv4 allocations. :) You can route /48 or shorter (larger) How many sites do you have? If less than 192, /44 is perfect, unless some of those sites require more than a /48. Then, it gets more complicated :-) -Randy From rcarpen at network1.net Thu Oct 11 22:08:06 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 11 Oct 2012 18:08:06 -0400 (EDT) Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <20121011150959.2F4CCF87@resin11.mta.everyone.net> Message-ID: <1529022632.331781.1349993286942.JavaMail.root@network1.net> > > ---------------------------------------------------- > > > A /48 is 65536 /64s and a /44 is 16x65536 /64s. If you > > only need one subnet (1 subnet = 1 /64), why would you > > try to get 16x65536 subnets, rather than the 65536 you > > have in the /48? > ------------------------------------------------------- > > He said it was for multiple sites. > --------------------------------------------------- > > DOH! > Note to self: focus on the outage and don't respond to NANOG > while troubleshooting. ;-) > > > scott Sometimes a brief distraction can be therapeutic when under pressure ;-) -Randy From streiner at cluebyfour.org Thu Oct 11 22:15:03 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 11 Oct 2012 18:15:03 -0400 (EDT) Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <298704693.331779.1349993169198.JavaMail.root@network1.net> References: <298704693.331779.1349993169198.JavaMail.root@network1.net> Message-ID: On Thu, 11 Oct 2012, Randy Carpenter wrote: > You can route /48 or shorter (larger) > > How many sites do you have? If less than 192, /44 is perfect, unless > some of those sites require more than a /48. Then, it gets more > complicated :-) A /44 would give you 16 /48s. If you have 192 sites - assuming a /48 per site - you would want at least a /40. jms From bill at herrin.us Thu Oct 11 22:15:47 2012 From: bill at herrin.us (William Herrin) Date: Thu, 11 Oct 2012 18:15:47 -0400 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <298704693.331779.1349993169198.JavaMail.root@network1.net> References: <063217D1-6FAC-4AEA-ABF8-28DB35959402@netconsonance.com> <298704693.331779.1349993169198.JavaMail.root@network1.net> Message-ID: On Thu, Oct 11, 2012 at 6:06 PM, Randy Carpenter wrote: > How many sites do you have? If less than 192, /44 is > perfect, unless some of those sites require more than > a /48. Then, it gets more complicated :-) We're having a general math breakdown today. First Jeroen wants to fit 5 /48's in a /47 and now you want to fit 192 /48's in a /44. 48-44=4. 2^4=16. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Oct 11 22:11:09 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Oct 2012 15:11:09 -0700 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <50773774.9080807@unfix.org> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> <50773774.9080807@unfix.org> Message-ID: <55F2A736-44E7-47FA-9837-C0AD3ADAA862@delong.com> On Oct 11, 2012, at 2:17 PM, Jeroen Massar wrote: > On 2012-10-11 23:02 , Jo Rhett wrote: >> I've finally convinced $DAYJOB to deploy IPv6. Justification for the >> IP space is easy, however the truth is that a /64 is more than we >> need in all locations. However the last I heard was that you can't >> effectively announce anything smaller than a /48. Is this still >> true? >> >> Is this likely to change in the immediate future, or do I need to ask >> for a /44? > > A /64 is for a single link (broadcast domain, though with IPv6 multicast > domain is more appropriate). > > A /48 (or /56 for end-users for some of the RIRs) is for a single > end-site ("a different administrative domain and/or a different physical > location"). > > If you thus have 5 end-sites, you should have room for 5 /48s and thus a > /47 is what you can justify. > Couple of errors there, Jeroen? 1. 5 /48s is at least a /45, not a /47 which is only 2 /48s. 2. Joe lives in the ARIN region where allocations and assignments are done on nibble boundaries, so his /45 would be rounded up to a /44 (as would a /47) anyway. Owen From owen at delong.com Thu Oct 11 22:24:48 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Oct 2012 15:24:48 -0700 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: References: <063217D1-6FAC-4AEA-ABF8-28DB35959402@netconsonance.com> <298704693.331779.1349993169198.JavaMail.root@network1.net> Message-ID: <48E86E4E-79F8-459F-9E38-0B6C09DBC4EB@delong.com> Wow and I thought nibble boundaries would make the math easier than HD ratios. Here's the breakdown for those who are mathematically challenged: n sites prefix 0 Nothing. 1 /48 2-12 /44 13-191 /40 192-3071 /36 3072-49,151 /32 49,152-786,431 /28 If you're managing more than 786,431 sites, then you should be able to afford to hire someone who can properly handle the math. Owen From rcarpen at network1.net Thu Oct 11 22:42:50 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 11 Oct 2012 18:42:50 -0400 (EDT) Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: Message-ID: <312833018.331820.1349995370242.JavaMail.root@network1.net> ----- Original Message ----- > On Thu, Oct 11, 2012 at 6:06 PM, Randy Carpenter > wrote: > > How many sites do you have? If less than 192, /44 is > > perfect, unless some of those sites require more than > > a /48. Then, it gets more complicated :-) > > We're having a general math breakdown today. First Jeroen wants to > fit > 5 /48's in a /47 and now you want to fit 192 /48's in a /44. > > 48-44=4. 2^4=16. > > -Bill Yep... I don't know why, but I was thinking /40. So, 1 site = /48 2-12 sites = /44 13-192 sites = /40, and so on. NRPM 6.5.8.2 for details. /40 bumps you into the next price category, but it is a 1-time expense for endusers. -Randy From tvhawaii at shaka.com Thu Oct 11 23:02:32 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 11 Oct 2012 13:02:32 -1000 Subject: Roy Bates, "Prince Roy" of Sealand, dies at 90. References: Message-ID: Joly MacFie wrote: > James Grimmelmann's recent write up is worth reading > > http://works.bepress.com/cgi/viewcontent.cgi?article=1035&context=james_grimmelmann So many incredible stories in there...thanks for posting that link. From mysidia at gmail.com Thu Oct 11 23:11:50 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Oct 2012 18:11:50 -0500 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: References: <063217D1-6FAC-4AEA-ABF8-28DB35959402@netconsonance.com> <298704693.331779.1349993169198.JavaMail.root@network1.net> Message-ID: On 10/11/12, William Herrin wrote: > On Thu, Oct 11, 2012 at 6:06 PM, Randy Carpenter > wrote: >> How many sites do you have? If less than 192, /44 is >> perfect, unless some of those sites require more than >> a /48. Then, it gets more complicated :-) > > We're having a general math breakdown today. First Jeroen wants to fit > 5 /48's in a /47 and now you want to fit 192 /48's in a /44. > 48-44=4. 2^4=16. Right, last I checked the smallest integer >= Log base 2 of 5 is not less than or equal to 1, therefore, you will never fit 5 /48s in the network just by subtracting 1 from the prefix length. if you want a prefix /yy that will accommodate a certain number N of /xx Then you must ensure that 2^(xx - yy) >= N not 5^(xx -yy ) >= N > > -Bill -- -J From ag4ve.us at gmail.com Fri Oct 12 00:01:18 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 12 Oct 2012 00:01:18 +0000 Subject: best way to create entropy? Message-ID: in the past, i've done many different things to create entropy - encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a kernel. but, what is best? just whatever gets your cpu to peak or are some tasks better than others? From jof at thejof.com Fri Oct 12 00:08:00 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 11 Oct 2012 17:08:00 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are > some tasks better than others? Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/ Internally, it uses diodes that are reverse-biased just ever so close to the breakdown voltage such that they randomly flip state back and forth. Cheers, jof From tim at lifelike.com Fri Oct 12 00:08:01 2012 From: tim at lifelike.com (Tim Edwards) Date: Thu, 11 Oct 2012 17:08:01 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <859276ABDB1A4480866BF5FCDD04162E@lifelike.com> Nature, via radio active decay! http://www.fourmilab.ch/hotbits/ -- Tim Edwards c: 206-604-5776 On Thursday, October 11, 2012 at 5:01 PM, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are > some tasks better than others? > > From mysidia at gmail.com Fri Oct 12 00:20:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Oct 2012 19:20:02 -0500 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On 10/11/12, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are You are referring to the entropy pool used for /dev/random and crypto operations ? You could setup a video capture card or radio tuner card, tune it into a good noise source, and arrange for the bit stream to get written to /dev/random Because anything written to /dev/random gets mixed in / XOR'ed into the entropy pool > some tasks better than others? > -- -JH From jof at thejof.com Fri Oct 12 00:25:37 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 11 Oct 2012 17:25:37 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On Thu, Oct 11, 2012 at 5:20 PM, Jimmy Hess wrote: > On 10/11/12, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are > > You are referring to the entropy pool used for /dev/random and > crypto operations ? > > > You could setup a video capture card or radio tuner card, tune it into > a good noise source, and arrange for the bit stream to get written > to /dev/random Yes, but then you're also introducing a way for an external attacker to transmit data that can be mixed into your entropy pool. While certainly a cool hack, I don't think anything like this would be safe for cryptographic use. Cheers, jof From pelzi at pelzi.net Fri Oct 12 00:43:35 2012 From: pelzi at pelzi.net (Jussi Peltola) Date: Fri, 12 Oct 2012 03:43:35 +0300 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <20121012004335.GB1563@pokute.pelzi.net> On Thu, Oct 11, 2012 at 05:25:37PM -0700, Jonathan Lassoff wrote: > Yes, but then you're also introducing a way for an external attacker > to transmit data that can be mixed into your entropy pool. XORring predictable data to random data does not yield a predictable result. /dev/random is world writable so if writing to it causes the random generator to output something predictable it's a bug that needs to be fixed. Also, an analog TV receiver will always have some noise that is not predictable even if you are transmitting a known signal to it. If you seriously need good entropy for cryptography, I think you will not ask about it on nanog, and I'd be very wary of cheap hardware RNGs too. From owen at delong.com Fri Oct 12 00:43:15 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Oct 2012 17:43:15 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <49EF6B3E-5DC3-42AB-8E3F-C637115477CD@delong.com> On Oct 11, 2012, at 5:01 PM, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are > some tasks better than others? I find that giving a screwdriver and a hammer to a child between the ages of 4 and 10 will usually do pretty well. Owen From ag4ve.us at gmail.com Fri Oct 12 00:48:05 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 12 Oct 2012 00:48:05 +0000 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On Fri, Oct 12, 2012 at 12:25 AM, Jonathan Lassoff wrote: > On Thu, Oct 11, 2012 at 5:20 PM, Jimmy Hess wrote: >> On 10/11/12, shawn wilson wrote: >>> in the past, i've done many different things to create entropy - >>> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >>> kernel. but, what is best? just whatever gets your cpu to peak or are >> >> You are referring to the entropy pool used for /dev/random and >> crypto operations ? >> >> >> You could setup a video capture card or radio tuner card, tune it into >> a good noise source, and arrange for the bit stream to get written >> to /dev/random > > Yes, but then you're also introducing a way for an external attacker > to transmit data that can be mixed into your entropy pool. > > While certainly a cool hack, I don't think anything like this would be > safe for cryptographic use. > which i guess means my tcpdump is also a bad idea... i've heard of looking at radio, voltage, and video. i was really wondering about a good every day solution - something easily implemented on any computer. so maybe a way of getting random network traffic or something random from computers around you. i'm not verisign or any other type of company that needs to generate thousands of keys in a day, but sometimes i need to generate a half dozen or so, and my entropy runs out pretty quickly. the radio idea might work for me if i could get a wire and a cheap amplifier and plug it into a headphone jack or possibly figure out a ccd type thing on a motor that would give me noise for my sound card. but i was hoping for something even more simple than that - maybe wifi noise? From NANOG at enger.us Fri Oct 12 00:49:42 2012 From: NANOG at enger.us (Robert M. Enger) Date: Thu, 11 Oct 2012 17:49:42 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <50776926.1030704@enger.us> On 10/11/2012 5:08 PM, Jonathan Lassoff wrote: > On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are >> some tasks better than others? > Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/ > > Internally, it uses diodes that are reverse-biased just ever so close > to the breakdown voltage such that they randomly flip state back and > forth. > > Cheers, > jof > Intel claims to include a hardware Digital Random Number Generator (DRNG) in its later generation chips. Is their offering inadequate/discredited? http://en.wikipedia.org/wiki/RdRand http://www.pcmag.com/article2/0,2817,2391367,00.asp http://www.intel.com/p/en_US/embedded/innovation/security/walker-article-security http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ From ag4ve.us at gmail.com Fri Oct 12 01:04:49 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 12 Oct 2012 01:04:49 +0000 Subject: best way to create entropy? In-Reply-To: <50776926.1030704@enger.us> References: <50776926.1030704@enger.us> Message-ID: On Fri, Oct 12, 2012 at 12:49 AM, Robert M. Enger wrote: > On 10/11/2012 5:08 PM, Jonathan Lassoff wrote: >> >> On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >>> >>> in the past, i've done many different things to create entropy - >>> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >>> kernel. but, what is best? just whatever gets your cpu to peak or are >>> some tasks better than others? >> >> Personally, I've used and recommend this USB stick: >> http://www.entropykey.co.uk/ >> >> Internally, it uses diodes that are reverse-biased just ever so close >> to the breakdown voltage such that they randomly flip state back and >> forth. >> >> Cheers, >> jof >> > Intel claims to include a hardware Digital Random Number Generator (DRNG) in > its later generation chips. Is their offering inadequate/discredited? > > http://en.wikipedia.org/wiki/RdRand > http://www.pcmag.com/article2/0,2817,2391367,00.asp > http://www.intel.com/p/en_US/embedded/innovation/security/walker-article-security > http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ > that's good to know about. i'll have to remember it when tech moves along in a year or so. but, right now, i don't think i have that capability. also, i'd prefer to have a chip agnostic solution as a month or so ago, i wanted to create a key on a raspberry pi (should've just copied one over) and it took forever to generate enough entropy - even as i was compiling stuff. after that, i considered tcpdump. From marka at isc.org Fri Oct 12 01:11:30 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Oct 2012 12:11:30 +1100 Subject: best way to create entropy? In-Reply-To: Your message of "Thu, 11 Oct 2012 17:49:42 PDT." <50776926.1030704@enger.us> References: <50776926.1030704@enger.us> Message-ID: <20121012011131.CC7AE29A386E@drugs.dv.isc.org> In message <50776926.1030704 at enger.us>, "Robert M. Enger" writes: > On 10/11/2012 5:08 PM, Jonathan Lassoff wrote: > > On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: > >> in the past, i've done many different things to create entropy - > >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > >> kernel. but, what is best? just whatever gets your cpu to peak or are > >> some tasks better than others? > > Personally, I've used and recommend this USB stick: http://www.entropykey.c > o.uk/ > > > > Internally, it uses diodes that are reverse-biased just ever so close > > to the breakdown voltage such that they randomly flip state back and > > forth. > > > > Cheers, > > jof > > > Intel claims to include a hardware Digital Random Number Generator (DRNG) in > its later generation chips. Is their offering inadequate/discredited? > > http://en.wikipedia.org/wiki/RdRand > http://www.pcmag.com/article2/0,2817,2391367,00.asp > http://www.intel.com/p/en_US/embedded/innovation/security/walker-article-secu > rity > http://software.intel.com/en-us/articles/intel-digital-random-number-generato > r-drng-software-implementation-guide/ Which is about time. It's not like this hasn't been needed for 10+ years. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Fri Oct 12 03:12:08 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Oct 2012 22:12:08 -0500 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On 10/11/12, Jonathan Lassoff wrote: > Yes, but then you're also introducing a way for an external attacker > to transmit data that can be mixed into your entropy pool. The binary operations used to 'mix in' data preserve entropy, when non-random data is mixed in, given the birwise operation A (+) B. The result is guaranteed to have entropy no less than the entropy of A, and also guaranteed to have entropy no less than the entropy of B. The transmitter/source of data does not control the system's administrative structures, so it is not possible for one source of data to "reduce" or "compromise" the entropy of an entropy pool. An external attacker would have to have a way of making the other sources of entropy unavailable, and make sure the system over-estimates the amount of remaining entropy, to ensure _no_ new entropy is available, other than their fake entropy. That risk is dwarfed by the risk of physical tampering, installation of remote bugs to steal key material, etc. > While certainly a cool hack, I don't think anything like this would be > safe for cryptographic use. These methods of generating entropy, when implemented reasonably, are far better than perfectly adequate for the generation of random numbers for one time pads, and cryptographic keys for long term use; for very high security purposes, as in 3-letter agency use, multiple independent sources of entropy are recommended. For high security applications, actions should always be contemplated to detect or protect against tampering with the hardware and software, or using software to steal key material. That may involve the use of smart cards, or dedicated single-purpose hardware security modules to generate and store keys, so a general purpose computer never has access to the keys, only a very simple one, that performs just the required crypto operations, when the proper number of authorized users prove their identity and ask the device to perform crypto operations. For applications that don't require that... RF noise from one source fed to /dev/random is highly adequate :) > jof -- -JH From Valdis.Kletnieks at vt.edu Fri Oct 12 03:23:43 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Oct 2012 23:23:43 -0400 Subject: best way to create entropy? In-Reply-To: Your message of "Thu, 11 Oct 2012 19:20:02 -0500." References: Message-ID: <30593.1350012223@turing-police.cc.vt.edu> On Thu, 11 Oct 2012 19:20:02 -0500, Jimmy Hess said: > You could setup a video capture card or radio tuner card, tune it into > a good noise source Finally, a good use for political talk radio. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From dwhite at olp.net Fri Oct 12 03:54:53 2012 From: dwhite at olp.net (Dan White) Date: Thu, 11 Oct 2012 22:54:53 -0500 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <20121012035453.GA9743@dan.olp.net> On 10/11/12?17:08?-0700, Jonathan Lassoff wrote: >On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are >> some tasks better than others? > >Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/ > >Internally, it uses diodes that are reverse-biased just ever so close >to the breakdown voltage such that they randomly flip state back and >forth. +1. -- Dan White From ag4ve.us at gmail.com Fri Oct 12 04:05:22 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 12 Oct 2012 04:05:22 +0000 Subject: best way to create entropy? In-Reply-To: References: Message-ID: On Fri, Oct 12, 2012 at 12:08 AM, Jonathan Lassoff wrote: > On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are >> some tasks better than others? > > Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/ > > not sure how much others care about server entropy in general. however, after reading this: http://strugglers.net/~andy/blog/2010/06/06/adventures-in-entropy-part-1/ i'm basically sold on that entropykey. $30 for a entropy through electron tunneling with tons of failsafes.... wow. i might just have to get two so i can nail the other to a frame, hang it on a wall and geek out every now and again :) From SNaslund at medline.com Fri Oct 12 04:27:56 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 11 Oct 2012 23:27:56 -0500 Subject: best way to create entropy? In-Reply-To: <20121012035453.GA9743@dan.olp.net> References: <20121012035453.GA9743@dan.olp.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0CBCAC8A@MUNEXBE1.medline.com> I know that a popular method for generating random bit streams is to take radio (stellar) noise and convert it into a digital bit stream. Very popular among crypto geeks. Steven Naslund -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Thursday, October 11, 2012 10:55 PM To: Jonathan Lassoff Cc: North American Network Operators Group Subject: Re: best way to create entropy? On 10/11/12?17:08?-0700, Jonathan Lassoff wrote: >On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are >> some tasks better than others? > >Personally, I've used and recommend this USB stick: >http://www.entropykey.co.uk/ > >Internally, it uses diodes that are reverse-biased just ever so close >to the breakdown voltage such that they randomly flip state back and >forth. +1. -- Dan White From ml at kenweb.org Fri Oct 12 04:32:58 2012 From: ml at kenweb.org (ML) Date: Fri, 12 Oct 2012 00:32:58 -0400 Subject: Native IPv6 providers/datacenters list? In-Reply-To: References: <20121009143453.GA743@debian> <5E164EA7-4CBF-4A40-A9BB-2AD2A2439925@u13.net> Message-ID: <50779D7A.8090104@kenweb.org> On 10/9/2012 11:05 AM, Jared Mauch wrote: > On Oct 9, 2012, at 10:42 AM, Ryan Rawdon wrote: > >> On Oct 9, 2012, at 9:34 AM, Christopher J. Pilkington wrote: >> >>> I want to make an informed response to a comment made by our >>> CenturyLink rep regarding IPv6, in the context of SAVVIS not >>> being able to provide IPv6 at their DC3 facility: >>> >>>> There is only a handful of carriers that can provide that >>>> service today and CenturyLink (Legacy Qwest) happen to be one >>>> of them. >>> Is there a list of native IPv6 providers out there somewhere, >>> particularly one that includes hosting data centers (e.g., >>> SAVVIS), with which I could cluebat^Wshare with my rep? >>> >> I'm not sure about a list of facilities, but here's a start for transit providers who should be able to provide IPv6 connectivity: >> >> http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers > I'll come out in public and say that sometimes a backbone supports it but the datacenter group does not. This is quite common core -> edge deployment strategy with network technology. Some technology can grow from the edges inward, but IPv6 is not a technology that does it [well]. > > I've been observing some big increases in IPv6 traffic (its no longer measured in Mbps as from years ago, but in Gbps). I'm waiting for it to approach a fair percentage of the IPv4 traffic but there are some big steps being made by the networks and edges to bridge this gap. > > - Jared Avoiding providers that can't provide a complete [*] IPv6 routing table is recommended too. The wiki URL provided by Christopher states quite clearly the limitations of using certain providers... [1] For varying levels of completeness From r3boot at r3blog.nl Fri Oct 12 09:30:13 2012 From: r3boot at r3blog.nl (Lex van Roon) Date: Fri, 12 Oct 2012 11:30:13 +0200 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <5077E325.9060100@r3blog.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shawn, On 12/10/12 02:01, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or > are some tasks better than others? > Not necessary the best way, but haveged* might be interesting to try out. It generates entropy based on differences in the cpu timestamp counters. Linux-only though. gr, Lex *) http://www.issihosts.com/haveged/ - -- LRO-RIPE | 398E38C3 | 748D 6359 389B 4E5A 4A44 82F5 BEC5 07FD 398E 38C3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQd+MfAAoJEL7FB/05jjjDBwQH/iaHGxx2Qh7BGBKpVJoUtH29 XCMsoDDY7mplhy7Z5WJG7UbfSjm3V+JNA8z6w6rfmiVX87iJLz6o4tEWOSmi4uZZ yj5Zgu3bqIBzcDdPNZ/3QKCRVRVNyT5b9V/mquXnr0kRIh8ZfpHbXycWcV75V634 MUebTftiT34ZSk3AcCdC+sntukW9cmb7Iht/4p1WD0DBb7FvidqYI24ezIkX92wc ehZp4Iu8cNxAwhsezRFY3hIi/nyMjUFekO2sl9o3CoB7g/S/8uIHBwp9LmkhpNi8 L+JB7SV36cTNT0r8wfITDwas0LpWjau96HwrQQOMq/9rSAW55BvPa+btOgyGKcg= =XpPc -----END PGP SIGNATURE----- From everettt at mitre.org Fri Oct 12 12:53:57 2012 From: everettt at mitre.org (Everett, Thomas E.) Date: Fri, 12 Oct 2012 12:53:57 +0000 Subject: Typical additional latency for CGN? In-Reply-To: <50317.1349749781@turing-police.cc.vt.edu> Message-ID: <444E2C1B1FF867439C008535FFEBD83E0682752F@IMCMBX01.MITRE.ORG> Thomas E Everett bb Enterprise Systems Engineering & Exploitation [G091] National Cyber Operations & Support everettt at mitre.org MITRE -- 703.983.1400 Cell 978.852.2400 ----- Original Message ----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Monday, October 08, 2012 10:29 PM To: Tom Limoncelli Cc: nanog at nanog.org Subject: Re: Typical additional latency for CGN? On Sun, 07 Oct 2012 16:47:18 -0400, Tom Limoncelli said: > Have there been studies on how much latency CGN adds to a typical > internet user? I'd also be interested in anecdotes. Should we include the time spent talking to the help desk trying to resolve double-NAT'ing issues in the latency? From andy at strugglers.net Fri Oct 12 14:41:01 2012 From: andy at strugglers.net (Andy Smith) Date: Fri, 12 Oct 2012 14:41:01 +0000 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <20121012144101.GU3867@bitfolk.com> Hi Shawn, On Fri, Oct 12, 2012 at 04:05:22AM +0000, shawn wilson wrote: > not sure how much others care about server entropy in general. > however, after reading this: > http://strugglers.net/~andy/blog/2010/06/06/adventures-in-entropy-part-1/ They are fun though I still have not found a good way to monitor when they're being exhausted.. http://serverfault.com/questions/354532/how-to-tell-when-an-entropy-key-is-overloaded Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting From cscora at apnic.net Fri Oct 12 18:51:37 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Oct 2012 04:51:37 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201210121851.q9CIpbCp024873@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 13 Oct, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 428355 Prefixes after maximum aggregation: 179212 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 210510 Total ASes present in the Internet Routing Table: 42342 Prefixes per ASN: 10.12 Origin-only ASes present in the Internet Routing Table: 33732 Origin ASes announcing only one prefix: 15790 Transit ASes present in the Internet Routing Table: 5626 Transit-only ASes present in the Internet Routing Table: 145 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 833 Unregistered ASNs in the Routing Table: 302 Number of 32-bit ASNs allocated by the RIRs: 3372 Number of 32-bit ASNs visible in the Routing Table: 2984 Prefixes from 32-bit ASNs in the Routing Table: 8135 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 165 Number of addresses announced to Internet: 2605906540 Equivalent to 155 /8s, 82 /16s and 250 /24s Percentage of available address space announced: 70.4 Percentage of allocated address space announced: 70.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.8 Total number of prefixes smaller than registry allocations: 150110 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 103055 Total APNIC prefixes after maximum aggregation: 32567 APNIC Deaggregation factor: 3.16 Prefixes being announced from the APNIC address blocks: 103769 Unique aggregates announced from the APNIC address blocks: 42942 APNIC Region origin ASes present in the Internet Routing Table: 4776 APNIC Prefixes per ASN: 21.73 APNIC Region origin ASes announcing only one prefix: 1247 APNIC Region transit ASes present in the Internet Routing Table: 775 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 326 Number of APNIC addresses announced to Internet: 711102112 Equivalent to 42 /8s, 98 /16s and 142 /24s Percentage of available APNIC address space announced: 83.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, 131072-133119 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: 154566 Total ARIN prefixes after maximum aggregation: 78313 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 155412 Unique aggregates announced from the ARIN address blocks: 69394 ARIN Region origin ASes present in the Internet Routing Table: 15279 ARIN Prefixes per ASN: 10.17 ARIN Region origin ASes announcing only one prefix: 5782 ARIN Region transit ASes present in the Internet Routing Table: 1594 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1086699904 Equivalent to 64 /8s, 197 /16s and 185 /24s Percentage of available ARIN address space announced: 57.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 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: 109143 Total RIPE prefixes after maximum aggregation: 57365 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 111805 Unique aggregates announced from the RIPE address blocks: 71908 RIPE Region origin ASes present in the Internet Routing Table: 16895 RIPE Prefixes per ASN: 6.62 RIPE Region origin ASes announcing only one prefix: 8130 RIPE Region transit ASes present in the Internet Routing Table: 2723 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1941 Number of RIPE addresses announced to Internet: 648107044 Equivalent to 38 /8s, 161 /16s and 84 /24s Percentage of available RIPE address space announced: 94.2 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, 196608-199679 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: 43764 Total LACNIC prefixes after maximum aggregation: 8674 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 47162 Unique aggregates announced from the LACNIC address blocks: 22584 LACNIC Region origin ASes present in the Internet Routing Table: 1667 LACNIC Prefixes per ASN: 28.29 LACNIC Region origin ASes announcing only one prefix: 457 LACNIC Region transit ASes present in the Internet Routing Table: 319 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 694 Number of LACNIC addresses announced to Internet: 117535272 Equivalent to 7 /8s, 1 /16s and 114 /24s Percentage of available LACNIC address space announced: 70.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9570 Total AfriNIC prefixes after maximum aggregation: 2236 AfriNIC Deaggregation factor: 4.28 Prefixes being announced from the AfriNIC address blocks: 10042 Unique aggregates announced from the AfriNIC address blocks: 3537 AfriNIC Region origin ASes present in the Internet Routing Table: 563 AfriNIC Prefixes per ASN: 17.84 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 125 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 42157312 Equivalent to 2 /8s, 131 /16s and 69 /24s Percentage of available AfriNIC address space announced: 41.9 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 2974 11428 902 Korea Telecom (KIX) 17974 2365 830 54 PT TELEKOMUNIKASI INDONESIA 7545 1770 301 87 TPG Internet Pty Ltd 4755 1626 387 163 TATA Communications formerly 9829 1401 1154 41 BSNL National Internet Backbo 9583 1226 90 518 Sify Limited 4808 1113 2060 316 CNCGROUP IP network: China169 7552 1088 1062 14 Vietel Corporation 24560 1034 385 162 Bharti Airtel Ltd., Telemedia 9498 1022 310 74 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 3203 3727 173 bellsouth.net, inc. 7029 3128 990 162 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1926 678 128 PaeTec Communications, Inc. 22773 1907 2931 128 Cox Communications, Inc. 20115 1655 1582 618 Charter Communications 4323 1586 1155 392 Time Warner Telecom 30036 1344 268 753 Mediacom Communications Corp 7018 1265 10304 841 AT&T WorldNet Services 7011 1207 329 701 Citizens Utilities 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 8402 1774 544 16 Corbina telecom 2118 1396 97 14 EUnet/RELCOM Autonomous Syste 12479 848 776 64 Uni2 Autonomous System 34984 797 206 182 BILISIM TELEKOM 31148 725 37 9 FreeNet ISP 6830 723 2313 445 UPC Distribution Services 20940 708 224 539 Akamai Technologies European 13188 697 92 155 Educational Network 58113 603 67 364 LIR DATACENTER TELECOM SRL 8551 575 364 61 Bezeq International 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 2203 379 219 TVCABLE BOGOTA 28573 2102 1277 60 NET Servicos de Comunicao S.A 8151 1588 3028 355 UniNet S.A. de C.V. 7303 1566 1035 203 Telecom Argentina Stet-France 6503 1538 435 69 AVANTEL, S.A. 27947 728 74 91 Telconet S.A 3816 649 309 70 Empresa Nacional de Telecomun 11172 592 85 66 Servicios Alestra S.A de C.V 14420 589 87 101 CORPORACION NACIONAL DE TELEC 7738 586 1178 33 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 892 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 669 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 270 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 192 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 172 682 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3203 3727 173 bellsouth.net, inc. 7029 3128 990 162 Windstream Communications Inc 4766 2974 11428 902 Korea Telecom (KIX) 17974 2365 830 54 PT TELEKOMUNIKASI INDONESIA 10620 2203 379 219 TVCABLE BOGOTA 28573 2102 1277 60 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1926 678 128 PaeTec Communications, Inc. 22773 1907 2931 128 Cox Communications, Inc. 8402 1774 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3128 2966 Windstream Communications Inc 17974 2365 2311 PT TELEKOMUNIKASI INDONESIA 4766 2974 2072 Korea Telecom (KIX) 28573 2102 2042 NET Servicos de Comunicao S.A 10620 2203 1984 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 1785 1926 1798 PaeTec Communications, Inc. 22773 1907 1779 Cox Communications, Inc. 8402 1774 1758 Corbina telecom 7545 1770 1683 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:87 /12:242 /13:477 /14:849 /15:1546 /16:12440 /17:6493 /18:10830 /19:21151 /20:30404 /21:32445 /22:42915 /23:40129 /24:224184 /25:1304 /26:1608 /27:905 /28:178 /29:65 /30:17 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2618 3128 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1797 3203 bellsouth.net, inc. 8402 1489 1774 Corbina telecom 30036 1272 1344 Mediacom Communications Corp 22773 1246 1907 Cox Communications, Inc. 11492 1166 1203 Cable One 6503 1054 1538 AVANTEL, S.A. 1785 1016 1926 PaeTec Communications, Inc. 7011 946 1207 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:636 2:772 3:1 4:13 5:567 6:3 8:489 12:1976 13:1 14:670 15:11 16:3 17:6 20:27 23:202 24:1791 27:1371 31:1021 32:54 33:2 34:2 36:7 37:842 38:829 39:2 40:137 41:2764 42:158 44:3 46:1637 47:2 49:456 50:591 52:12 54:25 55:9 56:3 57:27 58:987 59:541 60:237 61:1291 62:937 63:1997 64:4282 65:2232 66:4531 67:2080 68:1157 69:3214 70:988 71:505 72:1872 74:2603 75:483 76:309 77:970 78:978 79:503 80:1245 81:970 82:629 83:536 84:522 85:1157 86:484 87:946 88:364 89:1848 90:304 91:5250 92:597 93:1501 94:1628 95:1122 96:396 97:325 98:964 99:39 100:29 101:269 103:1641 105:512 106:120 107:199 108:473 109:1592 110:804 111:963 112:444 113:713 114:621 115:899 116:889 117:736 118:961 119:1230 120:328 121:688 122:1640 123:1152 124:1334 125:1281 128:563 129:196 130:287 131:639 132:308 133:22 134:252 135:62 136:221 137:238 138:337 139:170 140:501 141:287 142:491 143:378 144:496 145:82 146:507 147:276 148:749 149:327 150:158 151:196 152:450 153:179 154:20 155:426 156:226 157:374 158:262 159:658 160:346 161:411 162:364 163:191 164:709 165:427 166:527 167:553 168:990 169:126 170:914 171:152 172:7 173:1662 174:625 175:449 176:778 177:1272 178:1625 180:1348 181:161 182:1087 183:305 184:595 185:28 186:2228 187:1323 188:1748 189:1595 190:5818 192:6048 193:5751 194:4611 195:3661 196:1231 197:234 198:3852 199:5075 200:5993 201:1962 202:8670 203:8703 204:4400 205:2545 206:2764 207:2839 208:4060 209:3632 210:2836 211:1532 212:2016 213:1816 214:891 215:88 216:5127 217:1563 218:571 219:314 220:1247 221:533 222:337 223:416 End of report From cidr-report at potaroo.net Fri Oct 12 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Oct 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201210122200.q9CM00po080928@wattle.apnic.net> This report has been generated at Fri Oct 12 21:13:29 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-10-12 429926 248635 06-10-12 430259 248727 07-10-12 430310 249244 08-10-12 430496 248855 09-10-12 430487 248725 10-10-12 430434 248954 11-10-12 430587 249109 12-10-12 430924 249238 AS Summary 42438 Number of ASes in routing system 17662 Number of ASes announcing only one prefix 3202 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113835232 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 12Oct12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 431084 249189 181895 42.2% All ASes AS6389 3202 177 3025 94.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2133 64 2069 97.0% NET Servicos de Comunicao S.A. AS4766 2979 942 2037 68.4% KIXS-AS-KR Korea Telecom AS17974 2365 623 1742 73.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3128 1451 1677 53.6% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1907 302 1605 84.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2203 817 1386 62.9% Telmex Colombia S.A. AS2118 1396 110 1286 92.1% RELCOM-AS OOO "NPO Relcom" AS4323 1590 398 1192 75.0% TWTC - tw telecom holdings, inc. AS7303 1567 453 1114 71.1% Telecom Argentina S.A. AS1785 1929 828 1101 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1626 554 1072 65.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1096 162 934 85.2% VIETEL-AS-AP Vietel Corporation AS8151 1594 712 882 55.3% Uninet S.A. de C.V. AS18101 1017 174 843 82.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1113 349 764 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 862 116 746 86.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 698 53 645 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7545 1771 1137 634 35.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1112 483 629 56.6% LEVEL3 Level 3 Communications AS36998 772 148 624 80.8% SDN-MOBITEL AS17676 708 87 621 87.7% GIGAINFRA Softbank BB Corp. AS22561 1039 432 607 58.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1001 409 592 59.1% VZGNI-TRANSIT - Verizon Online LLC AS24560 1034 442 592 57.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1034 450 584 56.5% GBLX Global Crossing Ltd. AS4780 840 266 574 68.3% SEEDNET Digital United Inc. AS4804 669 97 572 85.5% MPX-AS Microplex PTY LTD AS22047 580 34 546 94.1% VTR BANDA ANCHA S.A. Total 45049 12693 32356 71.8% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 65.111.16.0/20 AS26407 GUILFORD-COMMUNICATIONS - Guilford Communications, Inc. 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.39.128.0/19 AS11069 EGIX-INDY-AS-11069 - Egix, Inc. 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.120.16.0/21 AS19891 BML-AS Bill Me Later, Inc 185.6.116.0/22 AS19852 CITYTEL Sity Telecom LTD 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS52390 Administradora de Redes, S.A. 200.75.185.0/24 AS52390 Administradora de Redes, S.A. 200.75.186.0/23 AS52390 Administradora de Redes, S.A. 200.75.188.0/22 AS52390 Administradora de Redes, S.A. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 12 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Oct 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201210122200.q9CM016V080941@wattle.apnic.net> BGP Update Report Interval: 04-Oct-12 -to- 11-Oct-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31560 49589 2.4% 718.7 -- INSOURCE Insource LLC 2 - AS8402 45432 2.2% 27.8 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS1637 38219 1.8% 415.4 -- DNIC-AS-01637 - Headquarters, USAISC 4 - AS9829 33457 1.6% 35.7 -- BSNL-NIB National Internet Backbone 5 - AS38547 30925 1.5% 71.1 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED 6 - AS23966 29514 1.4% 84.3 -- LDN-AS-PK LINKdotNET Telecom Limited 7 - AS52107 23536 1.1% 735.5 -- CPOINT-AS LLC "C Point" 8 - AS22561 22532 1.1% 208.6 -- DIGITAL-TELEPORT - Digital Teleport Inc. 9 - AS10620 22189 1.1% 10.2 -- Telmex Colombia S.A. 10 - AS55714 21419 1.0% 85.0 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd 11 - AS29076 18326 0.9% 733.0 -- CITYTELECOM-AS Citytelecom.ru 12 - AS24560 17701 0.8% 60.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 13 - AS13118 16879 0.8% 351.6 -- ASN-YARTELECOM OJSC Rostelecom 14 - AS25620 15895 0.8% 77.9 -- COTAS LTDA. 15 - AS28573 15377 0.7% 11.8 -- NET Servicos de Comunicao S.A. 16 - AS8452 14155 0.7% 11.2 -- TE-AS TE-AS 17 - AS26827 13400 0.6% 744.4 -- EPBTELECOM - EPB Telecom 18 - AS9583 13224 0.6% 14.9 -- SIFY-AS-IN Sify Limited 19 - AS44436 13176 0.6% 399.3 -- EFFORTEL-AS LLC MyBox 20 - AS38264 12428 0.6% 55.5 -- WATEEN-IMS-PK-AS-AP National WiMAX/IMS environment TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21599 9795 0.5% 9795.0 -- NETDIRECT S.A. 2 - AS40009 5530 0.3% 5530.0 -- BITGRAVITY - BitGravity, Inc. 3 - AS16130 5488 0.3% 5488.0 -- FiberLink Networks 4 - AS19406 4046 0.2% 4046.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS29564 3800 0.2% 3800.0 -- ASN-ITALDATA Italdata S.p.A 6 - AS3 2765 0.1% 2004.0 -- SYRHANO CENTRE DE RESSOURCES INFORMATIQUE DE HAUTE-NORMANDIE (C.R.I.H.A.N.) 7 - AS14680 6674 0.3% 2224.7 -- REALE-6 - Auction.com 8 - AS6197 1167 0.1% 1167.0 -- BATI-ATL - BellSouth Network Solutions, Inc 9 - AS59645 1041 0.1% 1041.0 -- NETGATE-AS Netgate-Iraqi Company for Communication and Information Limited responsibility 10 - AS26520 848 0.0% 848.0 -- NATIONAL-PRINT-GROUP-INC - National Print Group, Inc. 11 - AS47033 1686 0.1% 843.0 -- BASENINE-RIVERSIDE - BaseNine, Inc. 12 - AS29888 1650 0.1% 825.0 -- UNUMPROVIDENT-AS - Unum Group 13 - AS30397 820 0.0% 820.0 -- CHOICEDATA - CHOICEDATA 14 - AS8014 819 0.0% 819.0 -- BATELNET - Bahamas Telecommunications Corporation 15 - AS27601 816 0.0% 816.0 -- NETALLIANT-TECHNOLOGIES - NetAlliant Technologies, LLC 16 - AS48383 1551 0.1% 775.5 -- DELTA-AS Delta LLC 17 - AS51214 774 0.0% 774.0 -- VIKS-NET Small Private Enterprise Viks 18 - AS36529 2316 0.1% 772.0 -- AXXA-RACKCO - Rackco.com 19 - AS3 769 0.0% 544.0 -- SYRHANO CENTRE DE RESSOURCES INFORMATIQUE DE HAUTE-NORMANDIE (C.R.I.H.A.N.) 20 - AS50548 761 0.0% 761.0 -- QWENET-AS Qwe.Net ISP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 16763 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.157.224.0/19 11270 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 122.161.0.0/16 11198 0.5% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 184.159.130.0/23 10613 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - 200.46.0.0/19 9795 0.4% AS21599 -- NETDIRECT S.A. 6 - 5.102.192.0/19 5937 0.3% AS47956 -- XFONE XFONE COMMUNICATION LTD 7 - 202.41.70.0/24 5667 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 8 - 64.185.168.0/24 5530 0.2% AS40009 -- BITGRAVITY - BitGravity, Inc. 9 - 77.235.147.0/24 5488 0.2% AS16130 -- FiberLink Networks 10 - 12.139.133.0/24 5402 0.2% AS14680 -- REALE-6 - Auction.com 11 - 95.128.195.0/24 5278 0.2% AS39915 -- PREM-AS Premiere Global Services 12 - 192.58.2.0/24 5064 0.2% AS6629 -- NOAA-AS - NOAA 13 - 192.58.232.0/24 4987 0.2% AS6629 -- NOAA-AS - NOAA 14 - 194.63.9.0/24 4702 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 15 - 182.64.0.0/16 4184 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 16 - 49.248.72.0/21 4148 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 17 - 69.38.178.0/24 4046 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 18 - 213.92.117.0/24 3800 0.2% AS29564 -- ASN-ITALDATA Italdata S.p.A 19 - 123.252.208.0/24 3504 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 20 - 215.65.61.0/24 2866 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 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 ryan at finnesey.com Sat Oct 13 04:05:34 2012 From: ryan at finnesey.com (Ryan Finnesey) Date: Sat, 13 Oct 2012 04:05:34 +0000 Subject: Wired access to SMS? In-Reply-To: References: <5689085792276961524@unknownmsgid> Message-ID: <3CD5C9B8E677CE45AF0E1EB95AA4EF582260AECE@BLUPRD0511MB401.namprd05.prod.outlook.com> I have been happy with the services from twilio Cheers Ryan -----Original Message----- From: Joly MacFie [mailto:joly at punkcast.com] Sent: Wednesday, October 10, 2012 8:24 PM To: Tim M Edwards Cc: nanog at nanog.org Subject: Re: Wired access to SMS? More precisely http://www.twilio.com/sms j On Tue, Oct 9, 2012 at 3:37 PM, Tim M Edwards wrote: > Twillio.com > > On Oct 9, 2012, at 12:36 PM, William Herrin wrote: > > > Hi Folks, > > > > I'm looking for a way to do wireline access to send and receive > > cellular phone short message service (SMS) messages. Despite all my > > google-fu, I have had limited luck finding anyone that meets my > > needs, so I'm hoping someone here has found the path through. My > > main criteria are: > > > > > > 1. Low quantity, high reliability. I'll want a few dozen phone > > numbers and effectively I'll be sending to and receiving from phones I own. > > 2. Wireline delivery to Honolulu and Northern Virginia. Dynamically > > move numbers between the two locations for failover purposes. > > 3. U.S. based carrier. Tying in to the SMS system via Europe isn't > > acceptable to my customer. > > 4. Solution must reach phones on all U.S. cellular carriers. > > 5. Price is a very distant fifth criteria to the preceding four. > > > > I can consider Internet based systems where the provider uses U.S. > > based facilities and ties in to a U.S. phone network, provided that > > my standards of reliability and redundancy are met by their > > infrastructure. > > > > Alternately, I can also consider a wireless carrier that can provide > > two SIM-based phones with the same phone number for sending and > > receiving SMS messages. I'd put the sims in a pair of modems and > > manage deduplication of the received messages in software. > > > > > > Has anybody had any luck with this kind of requirement? Which > > vendors should I talk to and who at the vendor? > > > > Thanks, > > Bill Herrin > > > > > > -- > > William D. Herrin ................ herrin at dirtside.com > > bill at herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > > > -- --------------------------------------------------------------- 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 betty at newnog.org Sat Oct 13 15:53:00 2012 From: betty at newnog.org (Betty Burke ) Date: Sat, 13 Oct 2012 11:53:00 -0400 Subject: [NANOG-announce] NANOG 56 Reminders Message-ID: NANOG Colleagues: If you have not yet registered for NANOG 56, to be held * October 21-24, 2012, at the Sheraton Dallas Hotel, please consider doing so soon. We are expecting strong attendance, with nearly 495 registered attendees as of this date. Registration fees are: * - Late Registration (non-member $600, member $575, student $100) - On-Site Registration starting October 21, 2012 (non-member $675, member $650, student $100) Consider registering now at http://www.nanog.org/meetings/nanog56/nanog56_registration.html To make your hotel reservation visit http://www.nanog.org/meetings/nanog56/hotel.html * * *The NANOG Program Committee has once again delivered a very strong and exciting program. In fact some additions continue to be added, check out the latest agenda at ** http://www.nanog.org/meetings/nanog56/agenda.php * * * * We hope many of you will make time to attend, (if not in person, join us for remotely) at the ** Community and Member Meeting ** on Sunday, October 21st, from 5:45-6:45 p.m. Hosted by the NANOG Board, this is an important opportunity to learn about organizational updates and to share your views with the Board and other NANOG committees. In addition, candidates for the 2012 open Board seats will be on hand to answer any questions regarding their interest in serving on the Board of Directors. * * * *A friendly reminder, NANOG Elections are entering into the final stages. ** Complete election information is found at the NANOG Elections web page http://www.nanog.org/governance/elections/2012elections/ * Be sure to participate and become a NANOG member. Full membership information found at http://www.nanog.org/membership_main.html We have a full slate of NANOG Sponsors, we hope you will visit them in Dallas and extend our community appreciation for their support. http://www.nanog.org/meetings/nanog56/sponsors.html. Again we have the ever famous NANOG Sponsors Socials, complete information found at http://www.nanog.org/meetings/nanog56/socials.html If you need help or have a comment or suggestion about meeting operations please send us an email to nanog-support at nanog.org. Hope see everyone in Dallas! Sincerely, Betty Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From randy at psg.com Sat Oct 13 19:01:51 2012 From: randy at psg.com (Randy Bush) Date: Sat, 13 Oct 2012 09:01:51 -1000 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: Jo Rhett wrote: > > I've finally convinced $DAYJOB to deploy IPv6. Justification for the > IP space is easy, however the truth is that a /64 is more than we need > in all locations. However the last I heard was that you can't > effectively announce anything smaller than a /48. Is this still true? > > Is this likely to change in the immediate future, or do I need to ask > for a /44? /48 is the new /24 randy From mansaxel at besserwisser.org Sat Oct 13 21:14:25 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 13 Oct 2012 23:14:25 +0200 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: <20121013211424.GD29034@besserwisser.org> Subject: Re: Is a /48 still the smallest thing you can route independently? Date: Sat, Oct 13, 2012 at 09:01:51AM -1000 Quoting Randy Bush (randy at psg.com): > /48 is the new /24 Except you can stuff pretty much into one. I'm numbering my entire workplace from one. 1500 people and 26 offices. Our v4 is a constrained /16, which is enough. But not more. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 FROZEN ENTREES may be flung by members of opposing SWANSON SECTS ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jasper at pointless.net Sat Oct 13 22:11:20 2012 From: jasper at pointless.net (Jasper Wallace) Date: Sat, 13 Oct 2012 23:11:20 +0100 (BST) Subject: best way to create entropy? In-Reply-To: <20121012035453.GA9743@dan.olp.net> References: <20121012035453.GA9743@dan.olp.net> Message-ID: On Thu, 11 Oct 2012, Dan White wrote: > On 10/11/12?17:08?-0700, Jonathan Lassoff wrote: > > On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: > > > in the past, i've done many different things to create entropy - > > > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > > > kernel. but, what is best? just whatever gets your cpu to peak or are > > > some tasks better than others? > > > > Personally, I've used and recommend this USB stick: > > http://www.entropykey.co.uk/ > > > > Internally, it uses diodes that are reverse-biased just ever so close > > to the breakdown voltage such that they randomly flip state back and > > forth. > > +1. and with ekeyd-egd-linux you can distribute the entropy from an entropykey over the net - great for giving vm some randomness. -- [http://pointless.net/] [0x2ECA0975] From ag4ve.us at gmail.com Sun Oct 14 05:43:53 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 14 Oct 2012 05:43:53 +0000 Subject: best way to create entropy? In-Reply-To: References: <20121012035453.GA9743@dan.olp.net> Message-ID: again, to add some input to my own question - i happened to be compiling openssh and found this in the install doc: NB. If you operating system supports /dev/random, you should configure OpenSSL to use it. OpenSSH relies on OpenSSL's direct support of /dev/random, or failing that, either prngd or egd PRNGD: If your system lacks kernel-based random collection, the use of Lutz Jaenicke's PRNGd is recommended. http://prngd.sourceforge.net/ EGD: The Entropy Gathering Daemon (EGD) is supported if you have a system which lacks /dev/random and don't want to use OpenSSH's internal entropy collection. http://www.lothar.com/tech/crypto/ hopefully i'll find the time to figure out what is different about "OpenSSH's internal entropy collection", the above systems, and haveged. On Sat, Oct 13, 2012 at 10:11 PM, Jasper Wallace wrote: > On Thu, 11 Oct 2012, Dan White wrote: > >> On 10/11/12 17:08 -0700, Jonathan Lassoff wrote: >> > On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> > > in the past, i've done many different things to create entropy - >> > > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> > > kernel. but, what is best? just whatever gets your cpu to peak or are >> > > some tasks better than others? >> > >> > Personally, I've used and recommend this USB stick: >> > http://www.entropykey.co.uk/ >> > >> > Internally, it uses diodes that are reverse-biased just ever so close >> > to the breakdown voltage such that they randomly flip state back and >> > forth. >> >> +1. > > and with ekeyd-egd-linux you can distribute the entropy from an entropykey > over the net - great for giving vm some randomness. > > -- > [http://pointless.net/] [0x2ECA0975] From fw at deneb.enyo.de Sun Oct 14 08:14:56 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 14 Oct 2012 10:14:56 +0200 Subject: DNS caches that support partitioning ? In-Reply-To: <20120817161309.86830.qmail@joyce.lan> (John Levine's message of "17 Aug 2012 16:13:09 -0000") References: <20120817161309.86830.qmail@joyce.lan> Message-ID: <87ipadtqpr.fsf@mid.deneb.enyo.de> * John Levine: > Are there DNS caches that allow you to partition the cache for > subtrees of DNS names? That is, you can say that all entries from > say, in-addr.arpa, are limited to 20% of the cache. You can build something like that using forwarders and most DNS caches. But it won't result in an exact split because cross-subtree CNAMEs and DNS delegations will cause caching outside the subtree. However, for in-addr.arpa, that's probably what you want anyway. From sh.vahabzadeh at gmail.com Sun Oct 14 09:48:10 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 14 Oct 2012 13:18:10 +0330 Subject: Attacking on Source Port 0 (ZERO) Message-ID: Hi everybody, Does any body know what kind of attack can be come to port 0? I see such a logs in my routers which make high cpu loads: MYROUTERIP:0 *41.78.77.178:2816* MYROUTERIP:0 *217.160.5.153:2816* Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sander at steffann.nl Sun Oct 14 10:26:57 2012 From: sander at steffann.nl (Sander Steffann) Date: Sun, 14 Oct 2012 12:26:57 +0200 Subject: best way to create entropy? In-Reply-To: References: <20121012035453.GA9743@dan.olp.net> Message-ID: <3D94301E-1252-4901-B1E5-233BB948686E@steffann.nl> Hi, When you let OpenSSH use the egd protocol directly it will get its entropy from an egd daemon. Otherwise it uses /dev/random. When you use ekeyd-egd-linux then you feed the entropy from the egd daemon to the pool used for /dev/random. That way you are not completely dependent on the egd daemon, and other applications that need entropy benefit from the better-filled pool. And yes, I run ekeyd-egd-linux on many VMs :-) Sander From rdobbins at arbor.net Sun Oct 14 13:43:58 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 14 Oct 2012 13:43:58 +0000 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: References: Message-ID: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> On Oct 14, 2012, at 4:48 PM, Shahab Vahabzadeh wrote: > Does any body know what kind of attack can be come to port 0? If it's protocol 0, instead of port 0, it's likely a packet-flooding DDoS attack. If it's port 0, you may be incorrectly blocking non-initial fragments. Alternately, it could represent a fragmented DDoS attack, either non-initial fragments fired directly against something on your network or as the result of a DNS reflection/amplification attack against something on your network. The log fragment you posted doesn't provide enough detail to make an informed judgement. Also, you should not place servers behind a stateful firewall, anyways. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From edward.dore at freethought-internet.co.uk Sun Oct 14 14:04:55 2012 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Sun, 14 Oct 2012 15:04:55 +0100 Subject: Is a /48 still the smallest thing you can route independently? In-Reply-To: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> References: <4FEF985E-0131-49BE-8407-76D04217A8BF@netconsonance.com> Message-ID: <3FED6C40-DDED-4104-BB0B-16CB32CB68C3@freethought-internet.co.uk> RIPE Labs had an interesting article about filtering of /48 prefixes earlier this year that might be of some interest to you: https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering There's also a useful RIPE Labs article on general prefix filtering lengths from August last year: https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths Edward Dore Freethought Internet On 11 Oct 2012, at 22:02, Jo Rhett wrote: > I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? > > Is this likely to change in the immediate future, or do I need to ask for a /44? > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet projects. > > > From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Sun Oct 14 14:59:52 2012 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Sun, 14 Oct 2012 16:59:52 +0200 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <5156296.MEI8IOv7rc@gentoovm> On Friday 12 October 2012 00:01:18 shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are > some tasks better than others? Haveged, every time. Linux 3.7 will be getting some improvements in terms of entropy collection, to the point that it may well render haveged unnecessary. Generally speaking I find that it's VMs that prove to suffer from low entropy (and thus benefit greatly from haveged) Regards, Oliver From karim.adel at gmail.com Sun Oct 14 17:41:01 2012 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 14 Oct 2012 19:41:01 +0200 Subject: CLI Roadmap Message-ID: Hello, I have never used any CLI other than Cisco so i am curious what useful and creative knobs and bolts are available for other network appliance Vendors. I guess what makes *NIX CLI/Shell so superior is that you can advanced stuff from the CLI using sed, awk and all the great tools there so maybe this is also one thing missing. Regards, Kim From rodrick.brown at gmail.com Sun Oct 14 17:55:11 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sun, 14 Oct 2012 13:55:11 -0400 Subject: CLI Roadmap In-Reply-To: References: Message-ID: <8551541143784800406@unknownmsgid> On Oct 14, 2012, at 1:42 PM, Kasper Adel wrote: > Hello, > > I have never used any CLI other than Cisco so i am curious what useful and > creative knobs and bolts are available for other network appliance Vendors. Eh?? > > I guess what makes *NIX CLI/Shell so superior is that you can advanced > stuff from the CLI using sed, awk and all the great tools there so maybe > this is also one thing missing. Unix philosophy says a program should do only one thing and do it well. The Unix shell/CLI allows one to solve problems by sewing together a sequence of small, specialized programs by piping the output of a simple shell command to another shell command to solve problems. > > Regards, > Kim From ag4ve.us at gmail.com Sun Oct 14 18:29:10 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 14 Oct 2012 18:29:10 +0000 Subject: CLI Roadmap In-Reply-To: <8551541143784800406@unknownmsgid> References: <8551541143784800406@unknownmsgid> Message-ID: On Sun, Oct 14, 2012 at 5:55 PM, Rodrick Brown wrote: > On Oct 14, 2012, at 1:42 PM, Kasper Adel wrote: > >> Hello, >> >> I have never used any CLI other than Cisco so i am curious what useful and >> creative knobs and bolts are available for other network appliance Vendors. > > Eh?? > >> >> I guess what makes *NIX CLI/Shell so superior is that you can advanced >> stuff from the CLI using sed, awk and all the great tools there so maybe >> this is also one thing missing. > > Unix philosophy says a program should do only one thing and do it > well. The Unix shell/CLI allows one to solve problems by sewing > together a sequence of small, specialized programs by piping the > output of a simple shell command to another shell command to solve > problems. > this is correct. however, baring the utilities, the unix shells are so far ahead of most appliances and windows cmd. my zsh does autocompletion of program parameters, hosts in the hosts file, directories over scp, etc. i know what type of repo i'm in and if git/hg, i know what branch as it is put in my path with a zle script. my autocomplete is case insensitive as well and i have a visual representation of options i can tab through when i autocomplete. if there is a hardware vendor that doesn't use *nux that is at this level, i'd sure like to know. as it is, i think that good kernels (along with the rest of the stack) are so hard to develop that i don't hardware vendors are likely to want to put much money into developing their own anymore when nice choices are available for free. ie, vyatta (though i disagree with them using linux over bsd because of the network stack) From sh.vahabzadeh at gmail.com Sun Oct 14 19:59:42 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 14 Oct 2012 23:29:42 +0330 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> Message-ID: Hi there, It was TCP and I think it was not a DDoS attack because the traffic was not heavy. But I see abnormal cpu usage (%99) in my BRAS's which are Cisco 7206 VXR. I think it act like a warm or some attacks which cause high CPU load in some IOS. Thanks On Sun, Oct 14, 2012 at 5:13 PM, Dobbins, Roland wrote: > > On Oct 14, 2012, at 4:48 PM, Shahab Vahabzadeh wrote: > > > Does any body know what kind of attack can be come to port 0? > > If it's protocol 0, instead of port 0, it's likely a packet-flooding DDoS > attack. > > If it's port 0, you may be incorrectly blocking non-initial fragments. > Alternately, it could represent a fragmented DDoS attack, either > non-initial fragments fired directly against something on your network or > as the result of a DNS reflection/amplification attack against something on > your network. > > The log fragment you posted doesn't provide enough detail to make an > informed judgement. Also, you should not place servers behind a stateful > firewall, anyways. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From nick at foobar.org Sun Oct 14 20:57:53 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 14 Oct 2012 21:57:53 +0100 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> Message-ID: <507B2751.6010004@foobar.org> On 14/10/2012 20:59, Shahab Vahabzadeh wrote: > But I see abnormal cpu usage (%99) in my BRAS's which are Cisco 7206 VXR. If you haven't already configured CoPP on your BRASs, you might want to look at deploying it. It won't solve this sort of problem, but it will probably help: > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html There are many other configuration examples and documentation pages on the web, but this one gives a good overview. Nick From quantumfoam at gmail.com Sun Oct 14 20:59:12 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Sun, 14 Oct 2012 16:59:12 -0400 Subject: Detection of Rogue Access Points Message-ID: Gentlemen, An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways: 1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network. 2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network. These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first. I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware. Any ideas? Thank you for your time, Jonathan Rogers From joe at nethead.com Sun Oct 14 21:23:02 2012 From: joe at nethead.com (Joe Hamelin) Date: Sun, 14 Oct 2012 14:23:02 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers wrote: > Gentlemen, > > > I'm looking for innovative ideas on how to find such a rogue device, > Check ARP tables for MAC address of wireless devices (first few nybbles show manufacturer.) Or for ports with multiple devices where you know there aren't switches. > ideally as soon as it is plugged in to the network. That's going to take some decent scripting. Left as an exercise... > -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From quantumfoam at gmail.com Sun Oct 14 21:34:11 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Sun, 14 Oct 2012 17:34:11 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: I should probably mention that we do not have any legitimate wireless devices at these locations. I realize that this complicates matters. The most recent one we found was found exactly like Joe suggested; we were looking at an ARP table for other reasons and found suspicious things (smartphones). --JR On Sun, Oct 14, 2012 at 5:30 PM, Tom Morris wrote: > I have used the wigle app as a scanning and direction finding tool.. it > works OK. Not automated really as you'd have to walk and watch the screen > but it works. > > I once walked into a glass wall inside a building while searching for a > rogue AP... FOMP!!!! > On Oct 14, 2012 5:02 PM, "Jonathan Rogers" wrote: > >> Gentlemen, >> >> An issue has come up in my organization recently with rogue access points. >> So far it has manifested itself two ways: >> >> 1. A WAP that was set up specifically to be transparent and provided >> unprotected wireless access to our network. >> >> 2. A consumer-grade wireless router that was plugged in and "just worked" >> because it got an address from DHCP and then handed out addresses on its >> own little network. >> >> These are at remote sites that are on their own subnets (10.100.x.0/24; >> about 130 of them so far). Each site has a decent Cisco router at the >> demarc that we control. The edge is relatively low-quality managed layer 2 >> switches that we could turn off ports on if we needed to, but we have to >> know where to look, first. >> >> I'm looking for innovative ideas on how to find such a rogue device, >> ideally as soon as it is plugged in to the network. With situation #2 we >> may be able to detect NAT going on that should not be there. Situation #1 >> is much more difficult, although I've seen some research material on how >> frames that originate from 802.11 networks look different from regular >> ethernet frames. Installation of an advanced monitoring device at each >> site >> is not really practical, but we may be able to run some software on a >> Windows PC in each office. One idea put forth was checking for NTP traffic >> that was not going to our authorized NTP server, but NTP isn't necessarily >> turned on by default, especially on consumer-grade hardware. >> >> Any ideas? >> >> Thank you for your time, >> >> Jonathan Rogers >> > From lyndon at orthanc.ca Sun Oct 14 21:43:07 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 14 Oct 2012 14:43:07 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <5C7DC48C-B036-432B-8828-F5CE7F8BD1BD@orthanc.ca> > I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. There was a SIGCOMM paper a few years back that described a scheme based on measuring the the ACK delays of TCP sessions. In a nutshell, you can detect nodes on the wireless network by looking for the extra delay added by the radio link. It had very good accuracy, and caught new nodes quickly. It didn't require any prior knowledge of the network. I don't have a copy of the paper at hand, and I don't remember the title/author or the publication date (2007ish?), but maybe this will ring a bell for someone else on the list who does. --lyndon From dustin at rseng.net Sun Oct 14 21:47:19 2012 From: dustin at rseng.net (Dustin Jurman) Date: Sun, 14 Oct 2012 17:47:19 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <6B01C29BEA65E347A560D0306A33D63B040D870B2A6C@RSSBS08.rseng.net> Automated solution would be something like Air defense or Air Scout with sensors. Cheap solution would be to lock down your switches with port based authentication. Dustin Dustin Jurman CEO Rapid Systems Corporation 1211 N. West Shore Blvd. Suite 711 Tampa, FL 33607 Ph: 813-232-4887 http://www.rapidsys.com "Building Better Infrastructure"? -----Original Message----- From: Jonathan Rogers [mailto:quantumfoam at gmail.com] Sent: Sunday, October 14, 2012 5:34 PM To: Tom Morris; nanog at nanog.org Subject: Re: Detection of Rogue Access Points I should probably mention that we do not have any legitimate wireless devices at these locations. I realize that this complicates matters. The most recent one we found was found exactly like Joe suggested; we were looking at an ARP table for other reasons and found suspicious things (smartphones). --JR On Sun, Oct 14, 2012 at 5:30 PM, Tom Morris wrote: > I have used the wigle app as a scanning and direction finding tool.. > it works OK. Not automated really as you'd have to walk and watch the > screen but it works. > > I once walked into a glass wall inside a building while searching for > a rogue AP... FOMP!!!! > On Oct 14, 2012 5:02 PM, "Jonathan Rogers" wrote: > >> Gentlemen, >> >> An issue has come up in my organization recently with rogue access points. >> So far it has manifested itself two ways: >> >> 1. A WAP that was set up specifically to be transparent and provided >> unprotected wireless access to our network. >> >> 2. A consumer-grade wireless router that was plugged in and "just worked" >> because it got an address from DHCP and then handed out addresses on >> its own little network. >> >> These are at remote sites that are on their own subnets >> (10.100.x.0/24; about 130 of them so far). Each site has a decent >> Cisco router at the demarc that we control. The edge is relatively >> low-quality managed layer 2 switches that we could turn off ports on >> if we needed to, but we have to know where to look, first. >> >> I'm looking for innovative ideas on how to find such a rogue device, >> ideally as soon as it is plugged in to the network. With situation #2 >> we may be able to detect NAT going on that should not be there. >> Situation #1 is much more difficult, although I've seen some research >> material on how frames that originate from 802.11 networks look >> different from regular ethernet frames. Installation of an advanced >> monitoring device at each site is not really practical, but we may be >> able to run some software on a Windows PC in each office. One idea >> put forth was checking for NTP traffic that was not going to our >> authorized NTP server, but NTP isn't necessarily turned on by >> default, especially on consumer-grade hardware. >> >> Any ideas? >> >> Thank you for your time, >> >> Jonathan Rogers >> > From waehlisch at ieee.org Sun Oct 14 21:56:49 2012 From: waehlisch at ieee.org (Matthias Waehlisch) Date: Sun, 14 Oct 2012 23:56:49 +0200 Subject: Detection of Rogue Access Points In-Reply-To: <5C7DC48C-B036-432B-8828-F5CE7F8BD1BD@orthanc.ca> References: <5C7DC48C-B036-432B-8828-F5CE7F8BD1BD@orthanc.ca> Message-ID: On Sun, 14 Oct 2012, Lyndon Nerenberg wrote: > There was a SIGCOMM paper a few years back that described a scheme > based on measuring the the ACK delays of TCP sessions. In a nutshell, > you can detect nodes on the wireless network by looking for the extra > delay added by the radio link. It had very good accuracy, and caught > new nodes quickly. It didn't require any prior knowledge of the > network. > > I don't have a copy of the paper at hand, and I don't remember the > title/author or the publication date (2007ish?), but maybe this will > ring a bell for someone else on the list who does. > do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf ? Cheers matthias -- 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 lyndon at orthanc.ca Sun Oct 14 22:27:11 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 14 Oct 2012 15:27:11 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <5C7DC48C-B036-432B-8828-F5CE7F8BD1BD@orthanc.ca> Message-ID: On 2012-10-14, at 14:56 PM, Matthias Waehlisch wrote: > do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf > ? That's the one! From chipps at chipps.com Sun Oct 14 22:27:36 2012 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sun, 14 Oct 2012 17:27:36 -0500 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <017f01cdaa5b$1d716910$58543b30$@chipps.com> Scan for devices with open port 80 as these are managed by a GUI. -----Original Message----- From: Jonathan Rogers [mailto:quantumfoam at gmail.com] Sent: Sunday, October 14, 2012 3:59 PM To: nanog at nanog.org Subject: Detection of Rogue Access Points Gentlemen, An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways: 1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network. 2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network. These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first. I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware. Any ideas? Thank you for your time, Jonathan Rogers From aaron at heyaaron.com Sun Oct 14 22:44:03 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 14 Oct 2012 15:44:03 -0700 Subject: Detection of Rogue Access Points In-Reply-To: <017f01cdaa5b$1d716910$58543b30$@chipps.com> References: <017f01cdaa5b$1d716910$58543b30$@chipps.com> Message-ID: On Sun, Oct 14, 2012 at 3:27 PM, Kenneth M. Chipps Ph.D. wrote: > Scan for devices with open port 80 as these are managed by a GUI. > That'd be tough if they plug the WAN port into your network and remote access isn't enabled. -A From chipps at chipps.com Sun Oct 14 23:17:33 2012 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sun, 14 Oct 2012 18:17:33 -0500 Subject: Detection of Rogue Access Points In-Reply-To: References: <017f01cdaa5b$1d716910$58543b30$@chipps.com> Message-ID: <018901cdaa62$17a0bf20$46e23d60$@chipps.com> Scan the local network from the local network. From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] Sent: Sunday, October 14, 2012 5:44 PM To: Kenneth M. Chipps Ph.D. Cc: nanog at nanog.org Subject: Re: Detection of Rogue Access Points On Sun, Oct 14, 2012 at 3:27 PM, Kenneth M. Chipps Ph.D. wrote: Scan for devices with open port 80 as these are managed by a GUI. That'd be tough if they plug the WAN port into your network and remote access isn't enabled. -A From jof at thejof.com Mon Oct 15 00:11:20 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 14 Oct 2012 17:11:20 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access points. > So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. This is actually a really tough problem to solve without either total dictatorial control of your switchports or lots of telemetry and monitoring. At $DAYJOB, we detect the transparent bridge case by having a subset of AP hardware setup as "monitors" that listen to 802.11 frames on the various channels, keeping a log of the client MAC addresses and the BSSID that they're associated with. Then, by selecting out only those client MAC addresses that are not associated to a known BSSID that we control, we compare that set of "unknown" client MAC addresses to the Ethernet L2 FIBs on our switches and look for matches. If we see entries, than there is some 802.11 device bridging clients onto our network and we hunt it down from there. I've yet to see a solid methodology for detecting NATing devices, short of requiring 802.1x authentication using expiring keys and one-time passwords. :p Cheers, jof From ops.lists at gmail.com Mon Oct 15 00:36:50 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 15 Oct 2012 06:06:50 +0530 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: restricting the number of mac addresses per switch port to one for your dhcp pool too, though more than one ap clones mac addresses. and make it unpopulr for the usual use cases by firewalling off stuff like dropbox, siri and icloud. there is of course commercial wips gear like this .. http://www.airtightnetworks.com/home/solutions/wireless-intrusion-prevention.html On Monday, October 15, 2012, Jonathan Lassoff wrote: > On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers > > wrote: > > This is actually a really tough problem to solve without either total > dictatorial control of your switchports or lots of telemetry and > monitoring. > > At $DAYJOB, we detect the transparent bridge case by having a subset > of AP hardware setup as "monitors" that listen to 802.11 frames on the > various channels, keeping a log of the client MAC addresses and the > BSSID that they're associated with. > Then, by selecting out only those client MAC addresses that are not > associated to a known BSSID that we control, we compare that set of > "unknown" client MAC addresses to the Ethernet L2 FIBs on our switches > and look for matches. > > If we see entries, than there is some 802.11 device bridging clients > onto our network and we hunt it down from there. > > > I've yet to see a solid methodology for detecting NATing devices, > short of requiring 802.1x authentication using expiring keys and > one-time passwords. :p > > Cheers, > jof > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From mysidia at gmail.com Mon Oct 15 01:27:34 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 14 Oct 2012 20:27:34 -0500 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: On 10/14/12, Jonathan Lassoff wrote: > I've yet to see a solid methodology for detecting NATing devices, > short of requiring 802.1x authentication using expiring keys and > one-time passwords. :p Or implement network access protection, w IPsec between the hosts and the resources on the LAN; the systems behind the rogue NAT device won't be able to prove their identity, pass system health checks for antimalware, and get the x509 certificates required to communicate with hosts on the LAN... Packet sniffer, and look for packets sourced from hosts on the LAN with a TTL not matching the default TTL of OS'es in use on the network. Monitor ARP traffic. Start with the assumption that all devices are NAT devices, or malicious/unauthorized devices. Use TCP probes, to detect devices listening on common ports which can be identified as OSes (eg Windows, Printers, etc), which are known hosts on the network with a known user, or known purpose, and known to not be NAT devices. Delete known devices from the list of assumed rogue IP addresses. All the remaining IPs have to be investigated, and get their MAC address, hostname, and purpose documented. Once MAC addresses of all _known_ hosts are documented and manually verified, by process of elimination, you can detect any unknown IP addresses/MAC addresses, which might be any kind of unauthorized device. A NAT device is one example..... another example of an unauthorized device could be an unauthorized hardware keylogger/ network backdoor, with unauthorized connectivity to the LAN, and possible covert channels/backdoors/firewall bypasses. > Cheers, > jof -- -JH From rdobbins at arbor.net Mon Oct 15 02:02:49 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 15 Oct 2012 02:02:49 +0000 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> Message-ID: On Oct 15, 2012, at 2:59 AM, Shahab Vahabzadeh wrote: > I think it act like a warm or some attacks which cause high CPU load in some IOS. i.e., a DDoS attack. You should configure iACLs at your edge so that random sources on the Internet can't packet your routers. Hopefully, you have hardware-based edge devices, not just software-based devices and (awful) stateful firewalls - the days of software-based devices on the Internet were over years ago. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Oct 15 02:04:12 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 15 Oct 2012 02:04:12 +0000 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: <507B2751.6010004@foobar.org> References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> <507B2751.6010004@foobar.org> Message-ID: On Oct 15, 2012, at 3:57 AM, Nick Hilliard wrote: > If you haven't already configured CoPP on your BRASs, you might want to look at deploying it. CoPP is pretty much a wash on software-based boxes; it only really helps on hardware-based boxes. And iACLs is easier/a bigger win, anyways (though anyone using software-based boxes on the Internet in 2012 is just waiting to be zorched). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From ops.lists at gmail.com Mon Oct 15 02:09:56 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 15 Oct 2012 07:39:56 +0530 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: SSL throughout the network, with access control enforced using certificates is certainly a good idea. But most of the problem you face is metrics and inventory control of authorized devices. Commercial WIPS gear does a lot of this heavy lifting without your having to script it all yourself. On Monday, October 15, 2012, Jimmy Hess wrote: > A NAT device is one example..... > another example of an unauthorized device could be an unauthorized > hardware keylogger/ network backdoor, with unauthorized connectivity to > the LAN, and > possible covert channels/backdoors/firewall bypasses. > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From surfer at mauigateway.com Mon Oct 15 02:10:08 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 14 Oct 2012 19:10:08 -0700 Subject: Attacking on Source Port 0 (ZERO) Message-ID: <20121014191008.2F45209E@resin09.mta.everyone.net> --- sh.vahabzadeh at gmail.com wrote: From: Shahab Vahabzadeh It was TCP and I think it was not a DDoS attack because the traffic was not heavy. ------------------------------- Many/most DoS attacks do not push up the traffic levels considerably. You can see this when looking at packet per second (pps) rates. You may see high pps on the attacked machines, but no correlating large increase in bps traffic rates. scott From kauer at biplane.com.au Mon Oct 15 02:11:00 2012 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 15 Oct 2012 13:11:00 +1100 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <1350267060.2856.133.camel@karl> On Sun, 2012-10-14 at 16:59 -0400, Jonathan Rogers wrote: > An issue has come up in my organization recently with > rogue access points. No-one has said this yet, so I will - why are people working around your normal network policies? This is often a sign of something lacking that people need in their daily work. You can often reduce this sort of "innocent thievery" down to a manageable minimum simply by making sure that people have the tools they need to work. Sometimes it's cheaper to give people what they want than to prevent them taking it. Maybe at least consider that as an option. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From r.engehausen at gmail.com Mon Oct 15 02:32:22 2012 From: r.engehausen at gmail.com (Roy) Date: Sun, 14 Oct 2012 19:32:22 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <507B75B6.4070207@gmail.com> On 10/14/2012 1:59 PM, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access > points. So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. > > 2. A consumer-grade wireless router that was plugged in and "just > worked" because it got an address from DHCP and then handed out > addresses on its own little network. > > These are at remote sites that are on their own subnets > (10.100.x.0/24; about 130 of them so far). Each site has a decent > Cisco router at the demarc that we control. The edge is relatively > low-quality managed layer 2 switches that we could turn off ports on > if we needed to, but we have to know where to look, first. > > I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. With situation #2 > we may be able to detect NAT going on that should not be there. > Situation #1 is much more difficult, although I've seen some research > material on how frames that originate from 802.11 networks look > different from regular ethernet frames. Installation of an advanced > monitoring device at each site is not really practical, but we may be > able to run some software on a Windows PC in each office. One idea > put forth was checking for NTP traffic that was not going to our > authorized NTP server, but NTP isn't necessarily turned on by > default, especially on consumer-grade hardware. > > Any ideas? > > Thank you for your time, > > Jonathan Rogers > Install your own Access Points for official use and have them scan for SSIDs in the vicinity. Kills two birds. One you now have official wireless access and your AP can detect rogue SSIDs. From jon.p.sevier at gmail.com Mon Oct 15 03:00:31 2012 From: jon.p.sevier at gmail.com (Jon Sevier) Date: Sun, 14 Oct 2012 20:00:31 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access points. > So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. > > 2. A consumer-grade wireless router that was plugged in and "just worked" > because it got an address from DHCP and then handed out addresses on its > own little network. > > > There are wireless IDS/IPS products available that monitor not only the airspace, but the wire as well. Many of these products will also actively defend the airspace. Search for "wIDS" and/or "wIPS". Often the cost of purchasing and deploying these products is more expensive than the cost of implementing simple 802.1x port authentication though. If nothing else, set up guest wireless piped to a cheap broadband connection and create and/or enforce proper acceptable use policies on your LAN. The less you fight your users, the easier your job is. Of course all of this is dependent on the business and legal jurisdiction you are in. -Jon From ggm at apnic.net Mon Oct 15 04:33:16 2012 From: ggm at apnic.net (George Michaelson) Date: Mon, 15 Oct 2012 14:33:16 +1000 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. Message-ID: <0A86E081-63AC-4954-B655-F08C98C114B3@apnic.net> If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. APNIC will be switching to a new RPKI 'split' trust anchor system on the 25th of October. This change is needed to align APNIC administered resources with their allocation hierarchy. These resources will also be certified under each responsible parent registry at the appropriate time. In accordance with RFC6490 the old APNIC Trust Anchor Locator, associated certificate and repository will be removed, when the certificate expires on the 28th of October. 5 new Trust Anchor Locator (TAL) have been published. These will be kept up to date as an independent trust anchor set for resources maintained by APNIC. The production cycle will start on the 25th of October. Relying parties must add these new TAL by the 25th of October in order to maintain continuity of validation. If you have any questions please contact me. George Michaelson (ggm at apnic.net) Please add the following to your trust anchor set: rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuMLL96YV9pf0rZ4Ow/bk cgpoPfsRzkcgmisyCuMUdotHwrp8pepujhohatScRK09ILRrZYCdpX4121MJhqXC P3u3hy9fF0CeARKX/Q82nJccD4dtUp23UcFys8hwJgNYZI910ajkAxwNT//H/TFw oUYbzZGBR7o2awMc7GdQl/j6dgOkV6AfYy5DyDEgOUNHnUxED2rreefL/E2Fr2ST Esar6bTR4Tg4+nVF1PjAkgN0tKZYe4wZ6VmtqV/VTngSLysim6av7ki+JR3cVgVU OqXeh1vPjH2tNu6u9bX37ZrdVb6NBRer9I99IDbKvyhELb6nzo8+Q74zga9HI+Pf QwIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp6vscYtzhe0CfFk5Ro44 llPhsInXtfAxqfYmK7m9V3khkqK3d3/ZAW6pcJm7qW8XhEGl+F5mUeeLIm5JoIhr kT5B5M6uL0VlCCkZJH4h76ybOa83vWITNZEDy9L3c3nK4S+Basu3vYoE4ICXGG+J 7zg5Iw9saV+p03E2w1g16pt1QI3Cnggp6edkeWClEz3aPw/ULOIHb7YmatWwdERl tL9LsuMSKszQLUY7F4XVpxey/rJYAZgzDUh+b6813WAClCkkydNjsbviuekAWJbx sW7Mcw53u30K4g8MP03CjkDOubyoR4Qo99R1UQJCdrRsFKbSSfN/fOA4y7ikc3xs jQIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyoYPp3l3DWyPtLWrmRn4 Oux9hQ5bxd0SX/f6ygHxik+I3eMJP5J0Pr2e500tyXb2uKsX9kDqu/kckr+TUMhV BHd5yAv8OAE3YYEvpz/7uTX7cYy2yUeA76OEP75Y88OIQEzGpPLNpIzDxMggxuDh IhkA5xMiUJgVoEgmWSzR+MuRBjv2422wAGB5GpLgYsOjpwvG0VPmhnE+39+10ucQ CLt0Ny5kOR4an2tkvHjm7rzKDnFm8MWxPzAWESdf+8g7ITzSglqxDNiK5E5rdzNt h1Kvp+9RwaFArw6Ky1A4HhnoplN4EfKwxq0YamuKV0ZTTpWyT2+qDuE6sOfHRbJ0 5QIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwsQlXmEklLYApoDo7GEa NNTEGFPU5wJpi04iXuga2xn+g/TMLOlyJbjuPYRtRm/7VbRnN3m9Ta+WETy03+Fm EbXzB4xxhJKVik/ARHBnrBWhLyURy8Q5/XplE9cJein37IE1mIsbKM7o/90S225w 7GuvW7T4kjPWYmBFOywHWsfQO1EdsgiJrkz+Ab67ZkdSIiKHkf2UE6/MrbDEj+QK 9+s/vKH8BtDhaLmTWY+bVvfJ3+AWDH6roo1ozbl5yamQFbLOl3ns30f3yOJcNSNu /qgMQRRyp2sXXQovhTy8yqm3LFspaCWnTmQtBieWZwibuOa4Z27A1FzTMst2T4wY /wIDAQAB From peter.phaal at gmail.com Mon Oct 15 04:42:01 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Sun, 14 Oct 2012 21:42:01 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: Do the layer 2 switches include sFlow instrumentation? http://sflow.org/products/network.php The following paper describes how IP TTL values can help identify unauthorized NAT devices. http://www.sflow.org/detectNAT/ Peter On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access points. > So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. > > 2. A consumer-grade wireless router that was plugged in and "just worked" > because it got an address from DHCP and then handed out addresses on its > own little network. > > These are at remote sites that are on their own subnets (10.100.x.0/24; > about 130 of them so far). Each site has a decent Cisco router at the > demarc that we control. The edge is relatively low-quality managed layer 2 > switches that we could turn off ports on if we needed to, but we have to > know where to look, first. > > I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. With situation #2 we > may be able to detect NAT going on that should not be there. Situation #1 > is much more difficult, although I've seen some research material on how > frames that originate from 802.11 networks look different from regular > ethernet frames. Installation of an advanced monitoring device at each site > is not really practical, but we may be able to run some software on a > Windows PC in each office. One idea put forth was checking for NTP traffic > that was not going to our authorized NTP server, but NTP isn't necessarily > turned on by default, especially on consumer-grade hardware. > > Any ideas? > > Thank you for your time, > > Jonathan Rogers From maxsec at gmail.com Mon Oct 15 05:36:52 2012 From: maxsec at gmail.com (Martin Hepworth) Date: Mon, 15 Oct 2012 06:36:52 +0100 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: How about some of the free network auditing tools like nmap even Spiceworks to detect the devices on your network? Martin On Sunday, 14 October 2012, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access points. > So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. > > 2. A consumer-grade wireless router that was plugged in and "just worked" > because it got an address from DHCP and then handed out addresses on its > own little network. > > These are at remote sites that are on their own subnets (10.100.x.0/24; > about 130 of them so far). Each site has a decent Cisco router at the > demarc that we control. The edge is relatively low-quality managed layer 2 > switches that we could turn off ports on if we needed to, but we have to > know where to look, first. > > I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. With situation #2 we > may be able to detect NAT going on that should not be there. Situation #1 > is much more difficult, although I've seen some research material on how > frames that originate from 802.11 networks look different from regular > ethernet frames. Installation of an advanced monitoring device at each site > is not really practical, but we may be able to run some software on a > Windows PC in each office. One idea put forth was checking for NTP traffic > that was not going to our authorized NTP server, but NTP isn't necessarily > turned on by default, especially on consumer-grade hardware. > > Any ideas? > > Thank you for your time, > > Jonathan Rogers > -- -- Martin Hepworth, CISSP Oxford, UK From Valdis.Kletnieks at vt.edu Mon Oct 15 15:05:44 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 15 Oct 2012 11:05:44 -0400 Subject: Detection of Rogue Access Points In-Reply-To: Your message of "Mon, 15 Oct 2012 13:11:00 +1100." <1350267060.2856.133.camel@karl> References: <1350267060.2856.133.camel@karl> Message-ID: <33012.1350313544@turing-police.cc.vt.edu> On Mon, 15 Oct 2012 13:11:00 +1100, Karl Auer said: > No-one has said this yet, so I will - why are people working around your > normal network policies? This is often a sign of something lacking that > people need in their daily work. You can often reduce this sort of > "innocent thievery" down to a manageable minimum simply by making sure > that people have the tools they need to work. > > Sometimes it's cheaper to give people what they want than to prevent > them taking it. Maybe at least consider that as an option. Amen to that - detecting rogue access points is one thing, but in order to make the users stop doing it, you're going to need either a sufficiently large carrot or a sufficiently large stick. If you don't deploy at least one, the problem *will* keep recurring. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From quantumfoam at gmail.com Mon Oct 15 15:12:30 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Mon, 15 Oct 2012 11:12:30 -0400 Subject: Detection of Rogue Access Points In-Reply-To: <33012.1350313544@turing-police.cc.vt.edu> References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> Message-ID: Well, quite frankly they have the tools they need. Our remote sites do not have any devices that require wireless. They don't have company-issued laptops, and personal laptops are not allowed. The policy is on the books but it isn't my department to make sure people know about it and follow it. Our end users at these branch offices are typically not very technically inclined and have no idea what a security risk this is (especially considering that we have EPHI on our network, although I can't really say more in detail than that). The person who put in the WAP I discovered doesn't even work for us any more. Port-based security might work, but our edge switches are total garbage (don't get me started, not in my control). I didn't find this WAP via nmap...it didn't show up. I believe it probably didn't have a valid management interface IP for some reason. We saw suspicious entries in the router's ARP table and starting looking around the office from there. --JR On Mon, Oct 15, 2012 at 11:05 AM, wrote: > On Mon, 15 Oct 2012 13:11:00 +1100, Karl Auer said: > > > No-one has said this yet, so I will - why are people working around your > > normal network policies? This is often a sign of something lacking that > > people need in their daily work. You can often reduce this sort of > > "innocent thievery" down to a manageable minimum simply by making sure > > that people have the tools they need to work. > > > > Sometimes it's cheaper to give people what they want than to prevent > > them taking it. Maybe at least consider that as an option. > > Amen to that - detecting rogue access points is one thing, but in order > to make the users stop doing it, you're going to need either a sufficiently > large carrot or a sufficiently large stick. If you don't deploy at least > one, > the problem *will* keep recurring. > From r.engehausen at gmail.com Mon Oct 15 15:54:25 2012 From: r.engehausen at gmail.com (Roy) Date: Mon, 15 Oct 2012 08:54:25 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> Message-ID: <507C31B1.8040006@gmail.com> Why not give them wireless Internet access only? That will keep all the smartphone users happy. On 10/15/2012 8:12 AM, Jonathan Rogers wrote: > Well, quite frankly they have the tools they need. Our remote sites do not > have any devices that require wireless. They don't have company-issued > laptops, and personal laptops are not allowed. The policy is on the books > but it isn't my department to make sure people know about it and follow it. > Our end users at these branch offices are typically not very technically > inclined and have no idea what a security risk this is (especially > considering that we have EPHI on our network, although I can't really say > more in detail than that). The person who put in the WAP I discovered > doesn't even work for us any more. > > Port-based security might work, but our edge switches are total garbage > (don't get me started, not in my control). I didn't find this WAP via > nmap...it didn't show up. I believe it probably didn't have a valid > management interface IP for some reason. We saw suspicious entries in the > router's ARP table and starting looking around the office from there. > > --JR > > ... From joe at nethead.com Mon Oct 15 16:00:56 2012 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Oct 2012 09:00:56 -0700 Subject: Detection of Rogue Access Points In-Reply-To: <507C31B1.8040006@gmail.com> References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 8:54 AM, Roy wrote: > > > Why not give them wireless Internet access only? That will keep all the > smartphone users happy. > > Maybe because he has 130 sites and 130 truck rolls is not cheap. Also company policy says no. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From tknchris at gmail.com Mon Oct 15 18:08:10 2012 From: tknchris at gmail.com (chris) Date: Mon, 15 Oct 2012 14:08:10 -0400 Subject: Anyone w/ clue @netsol? Message-ID: I am having a issue delivering mail to a specific domain hosted @netsol for a significant amount of time now (several days) only and getting a vague error from the remote side: inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try again later I have tried the support channels referenced on the netsol website called support phone num and emailed emailhelp at networksolutions.com and still cant seem to find anyone with a clue or get this escalated past level 1 call center staff. I have an existing open ticket for some time now If you are @netsol or have any good technical contacts please contact me offlist thanks chris From randy at psg.com Mon Oct 15 18:15:33 2012 From: randy at psg.com (Randy Bush) Date: Mon, 15 Oct 2012 08:15:33 -1000 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: > APNIC will be switching to a new RPKI 'split' trust anchor system on > the 25th of October. This change is needed to align APNIC administered > resources with their allocation hierarchy. These resources will also > be certified under each responsible parent registry at the appropriate > time. > ... > If you have any questions please contact me. ok. i'll bite. what the heck is this meant to support? i thought the rirs were moving from five TALs to one. randy, very confused From mikea at mikea.ath.cx Mon Oct 15 18:22:30 2012 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 15 Oct 2012 13:22:30 -0500 Subject: Anyone w/ clue @netsol? In-Reply-To: References: Message-ID: <20121015182229.GA46060@mikea.ath.cx> On Mon, Oct 15, 2012 at 02:08:10PM -0400, chris wrote: > I am having a issue delivering mail to a specific domain hosted > @netsol for a significant amount of time now (several days) only and > getting a vague error from the remote side: > > inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try > again later > > I have tried the support channels referenced on the netsol website > called support phone num and emailed emailhelp at networksolutions.com > and still cant seem to find anyone with a clue or get this escalated > past level 1 call center staff. > > I have an existing open ticket for some time now > > If you are @netsol or have any good technical contacts please contact > me offlist thanks I'm not @netsol, but am seeing the same thing. We have time-critical (and paid-for) oversize/overweight load permits stacking up for people at two different domains which point to mailhosts in netsol. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From tknchris at gmail.com Mon Oct 15 18:59:44 2012 From: tknchris at gmail.com (chris) Date: Mon, 15 Oct 2012 14:59:44 -0400 Subject: Anyone w/ clue @netsol? In-Reply-To: <20121015182229.GA46060@mikea.ath.cx> References: <20121015182229.GA46060@mikea.ath.cx> Message-ID: On Mon, Oct 15, 2012 at 2:22 PM, Mike A wrote: > On Mon, Oct 15, 2012 at 02:08:10PM -0400, chris wrote: >> I am having a issue delivering mail to a specific domain hosted >> @netsol for a significant amount of time now (several days) only and >> getting a vague error from the remote side: >> >> inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try >> again later >> >> I have tried the support channels referenced on the netsol website >> called support phone num and emailed emailhelp at networksolutions.com >> and still cant seem to find anyone with a clue or get this escalated >> past level 1 call center staff. >> >> I have an existing open ticket for some time now >> >> If you are @netsol or have any good technical contacts please contact >> me offlist thanks > > I'm not @netsol, but am seeing the same thing. We have time-critical (and > paid-for) oversize/overweight load permits stacking up for people at two > different domains which point to mailhosts in netsol. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > I am periodically not even able to connect to port 25 on that ip, I'm thinking overloaded box or cluster member fail? chris From joshbaird at gmail.com Mon Oct 15 19:06:36 2012 From: joshbaird at gmail.com (Josh Baird) Date: Mon, 15 Oct 2012 15:06:36 -0400 Subject: Anyone w/ clue @netsol? In-Reply-To: References: <20121015182229.GA46060@mikea.ath.cx> Message-ID: I'm thinking crappy monitoring tools. Josh On Mon, Oct 15, 2012 at 2:59 PM, chris wrote: > On Mon, Oct 15, 2012 at 2:22 PM, Mike A wrote: > > On Mon, Oct 15, 2012 at 02:08:10PM -0400, chris wrote: > >> I am having a issue delivering mail to a specific domain hosted > >> @netsol for a significant amount of time now (several days) only and > >> getting a vague error from the remote side: > >> > >> inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try > >> again later > >> > >> I have tried the support channels referenced on the netsol website > >> called support phone num and emailed emailhelp at networksolutions.com > >> and still cant seem to find anyone with a clue or get this escalated > >> past level 1 call center staff. > >> > >> I have an existing open ticket for some time now > >> > >> If you are @netsol or have any good technical contacts please contact > >> me offlist thanks > > > > I'm not @netsol, but am seeing the same thing. We have time-critical (and > > paid-for) oversize/overweight load permits stacking up for people at two > > different domains which point to mailhosts in netsol. > > > > -- > > Mike Andrews, W5EGO > > mikea at mikea.ath.cx > > Tired old sysadmin > > > > I am periodically not even able to connect to port 25 on that ip, I'm > thinking overloaded box or cluster member fail? > > chris > > From cra at WPI.EDU Mon Oct 15 19:23:50 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 15 Oct 2012 15:23:50 -0400 Subject: CLI Roadmap In-Reply-To: References: Message-ID: <20121015192350.GM25927@angus.ind.WPI.EDU> On Sun, Oct 14, 2012 at 07:41:01PM +0200, Kasper Adel wrote: > I have never used any CLI other than Cisco so i am curious what useful and > creative knobs and bolts are available for other network appliance Vendors. Junos OS has: - Multi-level hierarchical configuration with absolute or relative configuration editing, comments (annotations), and XML support. Hierarchical configuration: [edit] user at device# show | find interfaces interfaces { ge-0/0/0 { description "foo"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 10 { description "bar"; vlan-id 10; family inet { address 10.1.2.3/24; } } } } Absolute (from the root of the configuration tree) editing: [edit] user at device# set interfaces ge-0/0/0 description "foo" [edit] user at device# set interfaces ge-0/0/0 flexible-vlan-tagging [edit] user at device# set interfaces ge-0/0/0 encapsulation flexible-ethernet-services [edit] user at device# set interfaces ge-0/0/0 unit 10 description "bar" [edit] user at device# set interfaces ge-0/0/0 unit 10 vlan-id 10 [edit] user at device# set interfaces ge-0/0/0 unit 10 family inet address 10.1.2.3/24 Relative (from any level in the configuration tree) editing: [edit] user at device# edit interfaces [edit interfaces] user at device# edit ge-0/0/0 unit 10 [edit interfaces ge-0/0/0 unit 10] user at device# show description "foo"; vlan-id 10; family inet { address 10.1.2.3/24; } [edit interfaces ge-0/0/0 unit 10] user at device# set vlan-id 20 [edit interfaces ge-0/0/0 unit 10] user at device# show | match vlan-id vlan-id 20; - Non-immediate configuration editing with commit/rollback functionality. - The ability to pre-configure hardware that isn't installed yet. - Configuration diff (compare), patch, merge, replace, etc. [edit interfaces ge-0/0/0 unit 10] user at device# set family inet mtu 9000 [edit interfaces ge-0/0/0 unit 10] user at device# show | compare [edit interfaces ge-0/0/0 unit 10 family inet] - mtu 1500; + mtu 9000; - Template & derived configurations (configuration groups, apply-groups, apply-path, interface-ranges which support GLOBs/regular expressions, etc.) - Scripting with Op Scripts (create CLI command extensions), Event Scripts (react to device events), and Configuration Scripts (modify the to-be-committed configuration in various ways). - Piping ala UNIX: user at device> show configuration | ? Possible completions: compare Compare configuration changes with prior version count Count occurrences display Show additional kinds of information except Show only text that does not match a pattern find Search for first occurrence of pattern hold Hold text without exiting the --More-- prompt last Display end of output only match Show only text that matches a pattern no-more Don't paginate output request Make system-level requests resolve Resolve IP addresses save Save output text to file trim Trim specified number of columns from start of line user at device> show configuration | display ? Possible completions: changed Tag changes with junos:changed attribute (XML only) commit-scripts Show data after commit scripts have been applied detail Show configuration data detail inheritance Show inherited configuration data and source group omit Emit configuration statements with the 'omit' option set Show 'set' commands that create configuration xml Show output as XML tags > I guess what makes *NIX CLI/Shell so superior is that you can advanced > stuff from the CLI using sed, awk and all the great tools there so maybe > this is also one thing missing. and if you really need the UNIX shell, Junos OS has that too with sed, awk, etc.: user at device> start shell % From ryan at u13.net Mon Oct 15 20:03:18 2012 From: ryan at u13.net (Ryan Rawdon) Date: Mon, 15 Oct 2012 15:03:18 -0500 Subject: Anyone w/ clue @netsol? In-Reply-To: References: Message-ID: <30ABBF15-3010-4912-9D20-4957B51B01FB@u13.net> On Oct 15, 2012, at 1:08 PM, chris wrote: > I am having a issue delivering mail to a specific domain hosted > @netsol for a significant amount of time now (several days) only and > getting a vague error from the remote side: Note that mail delivery issues to NetSol have been discussed over the past week on the mailop mailing list (where mail-related operations traffic has generally left NANOG for over the past few years): http://chilli.nosignal.org/mailman/listinfo/mailop > > inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try > again later > > I have tried the support channels referenced on the netsol website > called support phone num and emailed emailhelp at networksolutions.com > and still cant seem to find anyone with a clue or get this escalated > past level 1 call center staff. > > I have an existing open ticket for some time now > > If you are @netsol or have any good technical contacts please contact > me offlist thanks > > chris > From fw at deneb.enyo.de Mon Oct 15 20:34:46 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Oct 2012 22:34:46 +0200 Subject: Internet-wide port scans Message-ID: <87391fv5i1.fsf@mid.deneb.enyo.de> Are there somewhat reputable service providers for Internet-wide TCP port scans? What's the typical rate per TCP port? (I'm interested in rather obscure services whose identification may need additional probing, and this data is unlikely on file already.) A full scan needs just 0.5 TB of data per TCP port, so "roll your own" is definitely an option. But I expect that any halfway decent hosting provider will start asking questions after the first billion packets or so, and at least over here, broadband access without abuse management lacks sufficient upload bandwidth, making the results difficult to interpret because the measurements would span several days. From sean at seanharlow.info Mon Oct 15 23:06:23 2012 From: sean at seanharlow.info (Sean Harlow) Date: Mon, 15 Oct 2012 19:06:23 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 12:00 PM, Joe Hamelin wrote: > > Maybe because he has 130 sites and 130 truck rolls is not cheap. Also > company policy says no. > > You are correct that deploying to a number of sites isn't cheap, but the actual relevant question is how does this cost compare to the cost of the original request to detect these things. In this case almost all forms of detection/prevention except possibly looking at TTL will require new equipment to be deployed at the site(s) anyways based on the information we have, negating much of the extra cost. Any active detection on the RF side of things is generally done using WAPs in a managed network or standalone devices that are pretty much repurposed WAP hardware anyways, but cost a lot more. Both of those costs must then be compared to the cost of doing nothing. What happens if a user takes things in to their own hands and either leaves the AP open or uses some useless form of security (MAC filtering, WEP, WPA2 w/ WDS, WPA2 w/ weak password and a common SSID, etc.) allowing an attacker in to the network? If company policy says no, maybe company policy should be re-evaluated if enforcing said policy would cost more than the other options. Policy isn't supposed to be written in stone, it should adapt to the realities of the world as they change. Obviously this depends on the situation. Small business that uses mostly "cloud" services and doesn't have much if any local content to secure? Probably not worth doing anything. Three-letter agency? Worth every penny to detect and lock out unauthorized devices. Most will be somewhere in between, you have to evaluate the actual choices and decide the best path. From joe at nethead.com Mon Oct 15 23:31:34 2012 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Oct 2012 16:31:34 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 4:06 PM, Sean Harlow wrote: > > You are correct that deploying to a number of sites isn't cheap, but the > actual relevant question is how does this cost compare to the cost of the > original request to detect these things. In this case almost all forms of > detection/prevention except possibly looking at TTL will require new > equipment to be deployed at the site(s) anyways based on the information we > have, negating much of the extra cost. Any active detection on the RF side > of things is generally done using WAPs in a managed network or standalone > devices that are pretty much repurposed WAP hardware anyways, but cost a > lot more. > > I think it would be cheaper to have a script written that would grab the ARP table of each site and then compare to what is known. Kind of an ARP tripwire. Sure you'll have to take the time with early runs to hunt down non-company owned MACs but that is going to be a lot cheaper than managing a 130 site roll-out. Even if you did put RF monitoring equipment in each site you would still have to monitor and manage it. Either way, you'll be getting a current inventory of devices. From what I read, he wants to detect non-company equipment on his network. It's just WiFi that is the main problem. Even just watching the DHCP leases, which I assume the little Cisco router is providing, will catch most of the rouge devices. Get someone that knows networking and perl on the task for a month. If they don't have the local talent there are a lot of people that would love to take the contract, considering most of it could be done remotely. Jonathan stated that they have health data on the network and only company issued devices are allowed. I would suggest to him that he inventory the equipment via MAC address (I'm guessing that it's mostly standard issue stuff that would be easy to recognize) and then lock down unused ports and setup up monitoring. If a new MAC appears on the network, then it better have been sent there by IT. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From sean at seanharlow.info Tue Oct 16 00:29:32 2012 From: sean at seanharlow.info (Sean Harlow) Date: Mon, 15 Oct 2012 20:29:32 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 7:31 PM, Joe Hamelin wrote: > Jonathan stated that they have health data on the network and only company > issued devices are allowed. I would suggest to him that he inventory the > equipment via MAC address (I'm guessing that it's mostly standard issue > stuff that would be easy to recognize) and then lock down unused ports and > setup up monitoring. If a new MAC appears on the network, then it better > have been sent there by IT. > I won't argue with that. When no official wireless network is involved, a MAC whitelist can be very effective. It'll catch any casual user attempting to homebrew a WiFi setup and significantly increase the odds of detecting an actual attacker. Even if the switches are at the lowest end of "smart" and only expose a web interface it's not too hard to rig up a screen scraper to list the connected devices on a regular basis and alert if anything new is seen. I'd expect that there are probably at least a dozen commercial and/or open source tools that already exist for the purpose, actually. From george.herbert at gmail.com Tue Oct 16 00:44:16 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 15 Oct 2012 17:44:16 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 4:06 PM, Sean Harlow wrote: > On Mon, Oct 15, 2012 at 12:00 PM, Joe Hamelin wrote: > >> >> Maybe because he has 130 sites and 130 truck rolls is not cheap. Also >> company policy says no. >> >> > You are correct that deploying to a number of sites isn't cheap, but the > actual relevant question is how does this cost compare to the cost of the > original request to detect these things. In this case almost all forms of > detection/prevention except possibly looking at TTL will require new > equipment to be deployed at the site(s) anyways based on the information we > have, negating much of the extra cost. Any active detection on the RF side > of things is generally done using WAPs in a managed network or standalone > devices that are pretty much repurposed WAP hardware anyways, but cost a > lot more. > > Both of those costs must then be compared to the cost of doing nothing. > What happens if a user takes things in to their own hands and either leaves > the AP open or uses some useless form of security (MAC filtering, WEP, WPA2 > w/ WDS, WPA2 w/ weak password and a common SSID, etc.) allowing an attacker > in to the network? > > If company policy says no, maybe company policy should be re-evaluated if > enforcing said policy would cost more than the other options. Policy isn't > supposed to be written in stone, it should adapt to the realities of the > world as they change. > > Obviously this depends on the situation. Small business that uses mostly > "cloud" services and doesn't have much if any local content to secure? > Probably not worth doing anything. Three-letter agency? Worth every > penny to detect and lock out unauthorized devices. Most will be somewhere > in between, you have to evaluate the actual choices and decide the best > path. This solution - the "don't care" solution - almost fails the negligence test for certain security regimes including PCI (credit cards) and possibly SOX for retail data locations (and HIPPA for hospitals / medical locations, etc). That is not to say that there aren't still large numbers of poorly configured branch offices or retail locations out there at any number of retailers that fail those tests. Reality is painful. But if someone sticks in a WAP, starts sniffing credit card #s floating by, and your business finds itself on the arse end of a large painful data breach, you will regret not paying more attention beforehand. Not all networks are public networks. That said, adding another DSL line and router and public WAP just so that the store employees and the public's smartphones are happy is a perfectly reasonable service to offer. Separate from the security-critical data, or with really good firewalling / tunneling / whatever. -- -george william herbert george.herbert at gmail.com From ggm at algebras.org Tue Oct 16 00:44:26 2012 From: ggm at algebras.org (George Michaelson) Date: Tue, 16 Oct 2012 10:44:26 +1000 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: On 16/10/2012, at 4:15 AM, Randy Bush wrote: >> APNIC will be switching to a new RPKI 'split' trust anchor system on >> the 25th of October. This change is needed to align APNIC administered >> resources with their allocation hierarchy. These resources will also >> be certified under each responsible parent registry at the appropriate >> time. >> ... >> If you have any questions please contact me. > > ok. i'll bite. what the heck is this meant to support? i thought the > rirs were moving from five TALs to one. > > randy, very confused > Randy, we have an operational need to separate the existing single TAL into its discrete components for each source, so we can have production certificates for each source, so that we can ultimately have them signed under their appropriate parent registry, Once there is a global trust anchor, you can validate the 5 APNIC operating CA under a single root, single TAL. Until then, an APNIC TAL is necessary. -George From drc at virtualized.org Tue Oct 16 01:09:18 2012 From: drc at virtualized.org (David Conrad) Date: Mon, 15 Oct 2012 21:09:18 -0400 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: George, On Oct 15, 2012, at 8:44 PM, George Michaelson wrote: > Once there is a global trust anchor, you can validate the 5 APNIC operating > CA under a single root, single TAL. Until then, an APNIC TAL is necessary. So, just to be clear, the lack of a single TAL is due to inaction on the part of ICANN? Thanks, -drc From sean at seanharlow.info Tue Oct 16 01:17:11 2012 From: sean at seanharlow.info (Sean Harlow) Date: Mon, 15 Oct 2012 21:17:11 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 8:44 PM, George Herbert wrote: > This solution - the "don't care" solution - almost fails the > negligence test for certain security regimes including PCI (credit > cards) and possibly SOX for retail data locations (and HIPPA for > hospitals / medical locations, etc). > Of course, and this is where the situational judgement comes in to play. The low-security environments I was envisioning are those more like my own office, where the only on-site server is basically a homebrew NAS storing music/movies for slow days. We've jumped head first in to the Google Apps system so all files, mail, etc. are there. Payments and any other customer-facing services are on servers hosted in a proper datacenter, never coming close to the office LAN, so our actual risk is basically the same as that of a home user. The boss using his laptop on public WiFi worries me a lot more than someone gaining access to our network. If you take payments on-premise and transmit them over the network, it's obviously another story entirely. From djahandarie at gmail.com Tue Oct 16 01:18:31 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Mon, 15 Oct 2012 21:18:31 -0400 Subject: Internet-wide port scans In-Reply-To: <87391fv5i1.fsf@mid.deneb.enyo.de> References: <87391fv5i1.fsf@mid.deneb.enyo.de> Message-ID: On Mon, Oct 15, 2012 at 4:34 PM, Florian Weimer wrote: > A full scan needs just 0.5 TB of data per TCP port, so "roll your own" > is definitely an option. But I expect that any halfway decent hosting > provider will start asking questions after the first billion packets > or so, and at least over here, broadband access without abuse > management lacks sufficient upload bandwidth, making the results > difficult to interpret because the measurements would span several > days. Assuming you're scanning with 40 byte SYNs, you're going to be looking at an 84 byte Ethernet frame per port. If you're doing a 65535-port port scan, it'll use about 44Mbits of data. This means on a 1Gbit/s port, you could do around 22 scans per second. That'd be around 57.82 million scans a month. Buying a gig of cheap bandwidth for a month can cost $1000. So each scan would be about 0.002 cents if you just wanted to cover the costs. Of course this is assuming that you manage to have enough things to scan to do 22 per second for an entire month. Combine that with the fact that the person would most likely like to make a profit, and you'd be looking at probably at least 0.1 cents per scan. Either way, in the US at least, it's not legal to port scan random machines on the internet, so this was a rather useless exercise. (And I probably made some calculations errors anyways :) Not to mention that the tool would probably just be used to packet other sites, since 44Mbits is fairly non-negligible. Cheers. -- Darius Jahandarie From ggm at apnic.net Tue Oct 16 01:23:24 2012 From: ggm at apnic.net (George Michaelson) Date: Tue, 16 Oct 2012 11:23:24 +1000 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: On 16/10/2012, at 11:09 AM, David Conrad wrote: > George, > > On Oct 15, 2012, at 8:44 PM, George Michaelson wrote: >> Once there is a global trust anchor, you can validate the 5 APNIC operating >> CA under a single root, single TAL. Until then, an APNIC TAL is necessary. > > So, just to be clear, the lack of a single TAL is due to inaction on the part of ICANN? > > Thanks, > -drc > No David, no implication was intended that this is due to inaction on the part of ICANN. Sometimes, these things just take time. cheers -George From malayter at gmail.com Tue Oct 16 01:57:24 2012 From: malayter at gmail.com (Ryan Malayter) Date: Mon, 15 Oct 2012 20:57:24 -0500 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> Message-ID: <2F8495EC-B5A0-42CF-9503-DC917EC117BA@gmail.com> On Oct 14, 2012, at 9:02 PM, "Dobbins, Roland" wrote: > > Hopefully, you have hardware-based edge devices, not just software-based devices and (awful) stateful firewalls - the days of software-based devices on the Internet were over years ago. Software forwarding is usually only a problem if you have the $5 CPU that Cisco puts in their $30K boxes. The overwhelming majority of edge connections are <=1Gbps. A modern x86 can handle several of these connections *per core* at minimum packet sizes with stock Linux/BSD, including ACLs. 10G+ forwarding with minimum packet sizes is possible on a single core using optimized kernels (see Intel DPDK and PF_RING DNA). You don't need to handle more packets than you can possibly receive over your interfaces. From randy at psg.com Tue Oct 16 02:18:44 2012 From: randy at psg.com (Randy Bush) Date: Mon, 15 Oct 2012 16:18:44 -1000 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: >> ok. i'll bite. what the heck is this meant to support? i thought the >> rirs were moving from five TALs to one. > > Randy, we have an operational need to separate the existing single TAL > into its discrete components for each source, so we can have production > certificates for each source, so that we can ultimately have them signed > under their appropriate parent registry, ok, i'll give. what are the five 'sources'? randy From rdobbins at arbor.net Tue Oct 16 02:47:24 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 16 Oct 2012 02:47:24 +0000 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: <2F8495EC-B5A0-42CF-9503-DC917EC117BA@gmail.com> References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> <2F8495EC-B5A0-42CF-9503-DC917EC117BA@gmail.com> Message-ID: <344DEC22-59CA-4F1A-BD8B-1EC0D4260CA6@arbor.net> On Oct 16, 2012, at 8:57 AM, Ryan Malayter wrote: > 10G+ forwarding with minimum packet sizes is possible on a single core using optimized kernels (see Intel DPDK and PF_RING DNA). Of course it isn't. You can *approach* 10gb/sec with multiple cores and minimum packet sizes, granted. > You don't need to handle more packets than you can possibly receive over your interfaces. Yes, you do, because forwarding 64-byte packets at 'line-rate', whilst very important, isn't the only metric. I know all about the forwarding capabilities of modern general-purpose CPUs, ring-buffers, et. al. I know what is possible, and what isn't possible. And please, no more from the Vyatta crowd, et. al. - they're like the s/Flow shouters, only more so. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jay at miscreant.org Tue Oct 16 02:55:24 2012 From: jay at miscreant.org (Jay Mitchell) Date: Tue, 16 Oct 2012 13:55:24 +1100 Subject: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. In-Reply-To: References: <5EE40D85-91CC-4902-9F5D-B0B94197496A@apnic.net> Message-ID: <26969C30-02EC-427D-92A4-2D13D7631A35@miscreant.org> Perhaps the following? AfriNIC ARIN APNIC LACNIC RIPE Regards, Jay On 16/10/2012, at 1:18 PM, Randy Bush wrote: >>> ok. i'll bite. what the heck is this meant to support? i thought the >>> rirs were moving from five TALs to one. >> >> Randy, we have an operational need to separate the existing single TAL >> into its discrete components for each source, so we can have production >> certificates for each source, so that we can ultimately have them signed >> under their appropriate parent registry, > > ok, i'll give. what are the five 'sources'? > > randy > From snoble at sonn.com Tue Oct 16 03:59:20 2012 From: snoble at sonn.com (Steven Noble) Date: Mon, 15 Oct 2012 20:59:20 -0700 Subject: Attacking on Source Port 0 (ZERO) In-Reply-To: <344DEC22-59CA-4F1A-BD8B-1EC0D4260CA6@arbor.net> References: <98A6333A-8D74-470F-A477-48DF02D16445@arbor.net> <2F8495EC-B5A0-42CF-9503-DC917EC117BA@gmail.com> <344DEC22-59CA-4F1A-BD8B-1EC0D4260CA6@arbor.net> Message-ID: <9E6FA6F5-3A91-474A-98AA-FF1B75EF95CE@sonn.com> Roland, Sent from my iPhone On Oct 15, 2012, at 7:47 PM, "Dobbins, Roland" wrote: > I know all about the forwarding capabilities of modern general-purpose CPUs, ring-buffers, et. al. I know what is possible, and what isn't possible. And please, no more from the Vyatta crowd, et. al. - they're like the s/Flow shouters, only more so. What is possible these days with ivy bridge based CPUs and the DPDK? How many pps can you do per core assuming you are using the highest performing CPU currently commercially available? From surfer at mauigateway.com Tue Oct 16 04:57:35 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 15 Oct 2012 21:57:35 -0700 Subject: Internet-wide port scans Message-ID: <20121015215735.2F45B16A@resin09.mta.everyone.net> --- djahandarie at gmail.com wrote: From: Darius Jahandarie Either way, in the US at least, it's not legal to port scan random machines on the internet, so this was a rather useless exercise. (And ------------------------------------------------------ Want to re-write that section or should I respond now? ;-) scott From rjoffe at centergate.com Tue Oct 16 05:51:37 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 16 Oct 2012 01:51:37 -0400 Subject: 14 years ago today.... Message-ID: <0E04BA77-C294-4DFC-8E03-E31296C51881@centergate.com> ... we lost Jon. http://www.ietf.org/rfc/rfc2468.txt From baconzombie at gmail.com Tue Oct 16 07:14:40 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 16 Oct 2012 08:14:40 +0100 Subject: Internet-wide port scans In-Reply-To: <20121015215735.2F45B16A@resin09.mta.everyone.net> References: <20121015215735.2F45B16A@resin09.mta.everyone.net> Message-ID: Have a look at the talks done by Fyodor the creator of Nmap "Scanning the Internet". http://nmap.org/presentations/BHDC08/bhdc08-slides-fyodor.pdf http://www.securitytube.net/video/170 http://blog.thc.org/index.php?/archives/2-Port-Scanning-the-Internet.html Also if you are look for a host CloudSigma are open to Security Researches using their VPS system for this kind of work. http://www.cloudsigma.com/ ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????? On 16 Oct 2012 05:59, "Scott Weeks" wrote: > > > --- djahandarie at gmail.com wrote: > From: Darius Jahandarie > > Either way, in the US at least, it's not legal to port scan random > machines on the internet, so this was a rather useless exercise. (And > ------------------------------------------------------ > > > Want to re-write that section or should I respond now? ;-) > > scott > > From o.calvano at gmail.com Tue Oct 16 09:13:59 2012 From: o.calvano at gmail.com (Olivier CALVANO) Date: Tue, 16 Oct 2012 11:13:59 +0200 Subject: Search DSL Supplier in Italy Message-ID: Hi I am search good DSL (Adsl/Sdsl/EFM) supplier in Italy. delivred in ATM, L2TP or EThernet Vlan (no internet) Contact me best regards Olivier From jcdill.lists at gmail.com Tue Oct 16 09:41:35 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 16 Oct 2012 02:41:35 -0700 Subject: best way to create entropy? In-Reply-To: References: Message-ID: <507D2BCF.8070301@gmail.com> On 11/10/12 5:01 PM, shawn wilson wrote: > in the past, i've done many different things to create entropy - > encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a > kernel. but, what is best? just whatever gets your cpu to peak or are > some tasks better than others? You might want to take a look at: http://www.lavarnd.org/news/lavadiff.html jc From david at cantrell.org.uk Tue Oct 16 10:38:43 2012 From: david at cantrell.org.uk (David Cantrell) Date: Tue, 16 Oct 2012 11:38:43 +0100 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: <20121016103843.GA19792@bytemark.barnyard.co.uk> On Mon, Oct 15, 2012 at 09:00:56AM -0700, Joe Hamelin wrote: > On Mon, Oct 15, 2012 at 8:54 AM, Roy wrote: > > Why not give them wireless Internet access only? That will keep all the > > smartphone users happy. > Maybe because he has 130 sites and 130 truck rolls is not cheap. Also > company policy says no. So stick a pre-configured device in the post, with instructions on how and where to plug it in. -- David Cantrell | top google result for "topless karaoke murders" "Cynical" is a word used by the naive to describe the experienced. George Hills, in uknot From nick at foobar.org Tue Oct 16 10:44:04 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 16 Oct 2012 11:44:04 +0100 Subject: 100.100.0.0/24 In-Reply-To: <51F66CF419EDB149A49AA5401CD2E246BB3FF1@podcwmbxex506.ctl.intranet> References: <506DC4B8.30208@bogus.com> <506ED2C2.7090706@bogus.com> <84380913-C625-472E-8C6C-A19C8545F66D@puck.nether.net> <20121006203724.GA26642@panix.com> <1349566279.5173.4.camel@nymphadora.home.ludost.net> <50715C0D.2010303@foobar.org> <51F66CF419EDB149A49AA5401CD2E246BB3FF1@podcwmbxex506.ctl.intranet> Message-ID: <507D3A74.5000404@foobar.org> On 16/10/2012 11:37, Lowe, Richard B wrote: > Kind of like the 192.0.2.1/32 for IPv4, huh? no - 192.0.2.0/24 is formally "TEST-NET-1, documentation and examples", like 2001:db8::/32. 100::/64 is specifically for discard and analysis style RTBHs. I.e. for ipv6, you can now keep your documentation prefixes on your documentation. Nick > RFC: 5635 > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Sunday, October 07, 2012 6:40 AM > To: nanog at nanog.org > Subject: Re: 100.100.0.0/24 > > On 07/10/2012 00:34, Randy Bush wrote: >> ipv6 route 2001:DB8:0:DEAD:BEEF::1/128 Null0 > > plug: rfc 6666. > > 100::/64 is reserved for this purpose. > > Nick > > > > From djahandarie at gmail.com Tue Oct 16 12:48:47 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 16 Oct 2012 08:48:47 -0400 Subject: Internet-wide port scans In-Reply-To: <20121015215735.2F45B16A@resin09.mta.everyone.net> References: <20121015215735.2F45B16A@resin09.mta.everyone.net> Message-ID: On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: > Want to re-write that section or should I respond now? ;-) I always thought it wasn't allowed because of 18 USC ? 2701, but IINAL, would be happy to hear otherwise :). -- Darius Jahandarie From Valdis.Kletnieks at vt.edu Tue Oct 16 13:46:14 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Oct 2012 09:46:14 -0400 Subject: Internet-wide port scans In-Reply-To: Your message of "Tue, 16 Oct 2012 08:48:47 -0400." References: <20121015215735.2F45B16A@resin09.mta.everyone.net> Message-ID: <73969.1350395174@turing-police.cc.vt.edu> On Tue, 16 Oct 2012 08:48:47 -0400, Darius Jahandarie said: > On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: > > Want to re-write that section or should I respond now? ;-) > > I always thought it wasn't allowed because of 18 USC 2701, but > IINAL, would be happy to hear otherwise :) If a portscan allows access to stored communications, you have bigger problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Tue Oct 16 15:27:45 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 16 Oct 2012 11:27:45 -0400 (EDT) Subject: Internet-wide port scans In-Reply-To: <20121015215735.2F45B16A@resin09.mta.everyone.net> Message-ID: <30231730.30697.1350401265614.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Weeks" > From: Darius Jahandarie > > Either way, in the US at least, it's not legal to port scan random > machines on the internet, so this was a rather useless exercise. (And > ------------------------------------------------------ > > Want to re-write that section or should I respond now? ;-) I was gonna say {{citation-needed}}, myself, but yeah: "Huh?" Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From djahandarie at gmail.com Tue Oct 16 15:38:52 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 16 Oct 2012 11:38:52 -0400 Subject: Internet-wide port scans In-Reply-To: <73969.1350395174@turing-police.cc.vt.edu> References: <20121015215735.2F45B16A@resin09.mta.everyone.net> <73969.1350395174@turing-police.cc.vt.edu> Message-ID: On Tue, Oct 16, 2012 at 9:46 AM, wrote: > On Tue, 16 Oct 2012 08:48:47 -0400, Darius Jahandarie said: >> On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: >> > Want to re-write that section or should I respond now? ;-) >> >> I always thought it wasn't allowed because of 18 USC 2701, but >> IINAL, would be happy to hear otherwise :) > > If a portscan allows access to stored communications, you have bigger > problems. In particular, my understanding was that since you're sending a SYN, it could very well initiate access to stored communications (although that may have not been the intent of the SYN). But maybe I'm wrong -- and even if I'm right, this seems like something that probably wouldn't hold in court very well anyways. -- Darius Jahandarie From Valdis.Kletnieks at vt.edu Tue Oct 16 16:23:32 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Oct 2012 12:23:32 -0400 Subject: Internet-wide port scans In-Reply-To: Your message of "Tue, 16 Oct 2012 11:38:52 -0400." References: <20121015215735.2F45B16A@resin09.mta.everyone.net> <73969.1350395174@turing-police.cc.vt.edu> Message-ID: <17208.1350404612@turing-police.cc.vt.edu> On Tue, 16 Oct 2012 11:38:52 -0400, Darius Jahandarie said: > In particular, my understanding was that since you're sending a SYN, > it could very well initiate access to stored communications (although What 18 USC 2701 actually says, courtesy of www.law.cornell.edu: "Offense. - Except as provided in subsection (c) of this section whoever: (1) intentionally accesses without authorization a facility through which an electronic communication service is provided; or (2) intentionally exceeds an authorization to access that facility; and thereby obtains, alters, or prevents authorized access to a wire or electronic communication while it is in electronic storage in such system shall be punished as provided in subsection (b) of this section." First off, I believe (but don't have citation handy) there's actual case law that says that a SYN scan doesn't count as "access" (either without or exceeding authorization). And that's *stored* communications (in other words, your mail spool, not mail in-flight). You're better off chasing 18 USC 2511 (wiretapping, where the bits are in motion), and of course the 800 pound gorilla would be 18 USC 1030 (Fraud and related activity in connection with computers). And I'm pretty sure that an NMAP scan doesn't rise to the definition of 'accessed' for any of those. Of course, if the answer actually matters, ask a competent lawyer you've paid for advice. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From aaron.toponce at gmail.com Tue Oct 16 22:56:36 2012 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 16 Oct 2012 16:56:36 -0600 Subject: best way to create entropy? In-Reply-To: References: <20121012035453.GA9743@dan.olp.net> Message-ID: <20121016225634.GM11094@irc.ae7.st> On Sat, Oct 13, 2012 at 11:11:20PM +0100, Jasper Wallace wrote: > and with ekeyd-egd-linux you can distribute the entropy from an entropykey > over the net - great for giving vm some randomness. You would then be interested in http://hundun.ae7.st. Server I setup just a week or so ago doing this very thing. However, if using a server's random data, it's important you mix it into your /dev/random device, rather than using the data directly. After all, how can you trust the admin, that he's not keeping track of which client is receiving which data? -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From mcbride at countersiege.com Tue Oct 16 23:22:52 2012 From: mcbride at countersiege.com (Ryan McBride) Date: Wed, 17 Oct 2012 08:22:52 +0900 Subject: Detection of Rogue Access Points In-Reply-To: References: <1350267060.2856.133.camel@karl> <33012.1350313544@turing-police.cc.vt.edu> <507C31B1.8040006@gmail.com> Message-ID: <20121016232251.GC18289@countersiege.com> On Mon, Oct 15, 2012 at 04:31:34PM -0700, Joe Hamelin wrote: > I think it would be cheaper to have a script written that would grab the > ARP table of each site and then compare to what is known. Kind of an ARP > tripwire. Netdisco does this, and more (reports on ports which have more than 1 MAC address, devices from known wireless manufacturers, search MAC address by manufacturer, etc). http://www.netdisco.org/ From mysidia at gmail.com Tue Oct 16 23:43:34 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 16 Oct 2012 18:43:34 -0500 Subject: Internet-wide port scans In-Reply-To: References: <20121015215735.2F45B16A@resin09.mta.everyone.net> Message-ID: On 10/16/12, Darius Jahandarie wrote: > On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks > wrote: > I always thought it wasn't allowed because of 18 USC ? 2701, but > IINAL, would be happy to hear otherwise :). 18 USC 2701 is not necessarily the only consideration. I would rather say that there might be a risk of criminal and civil liability, for all entities intentionally participating in, assisting as accomplices in, or facilitating as service provider, software provider, providers of information or operating instructions, etc, for, anyone conducting or intentionally assisting an unauthorized port scan of a different ISP's address space, that varies with jurisdiction, and you should consult your counsel, to determine if any precautions are appropriate to manage the risk, such as obtaining proper Letters of authorization from IP address assignees in advance, or if the responsible entity determines that you must abstain from the activity entirely, because the risk level is too high. By definition a reputable service, will not have a policy that you may execute internet-wide port scans of arbitrary ports that include IP networks/addresses that are not either assigned to you, your ISP customer, or that you have specific written permission to scan, as they will want to manage the risks to themselves properly as well. Port scans are strongly associated with malicious activity. And there are other risks of adverse actions, besides legal ones, such as the service provider's address space becoming widely blacklisted or becoming depeered. Before a network service provider offers any kind of service that permits the SPs' services to be used for arbitrary port scans of other remote networks, they are likely to have taken steps to protect themselves, by setting some terms of use and policy restrictions on what conditions and parameters must be met, before a scan is allowed. > Darius Jahandarie -- -JH From jra at baylink.com Wed Oct 17 01:56:20 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 16 Oct 2012 21:56:20 -0400 (EDT) Subject: processing passwords? In-Reply-To: <20121015222611.GB27994@jpradley.jpr.com> Message-ID: <3472296.31051.1350438980863.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Pierre A. Radley" > | $ JRA=test echo $JRA > | > | does not work in the superficially obvious manner, but it makes > | sense > | after I think about it -- it's like trying to use sudo with > | redirection. > | > | That behavior is documented back to the v7 shell, I'm pretty sure, > | though > | my v7 UPM is at home. > | > > Your shell isn't behaving like mine, in that case. I start out in tcsh > and: > > jpradley:appl 6 sh > $ unset JPR > $ JPR=test echo $JPR > > $ echo $JPR > test tcsh, not especially to my surprise, does not meet the SVID or POSIX, then. _Unix Shell Programming_, Kochan and Wood, 1985, Hayden, p 251: "Another Way To Pass Variables To A Subshell If you want to send the value of a variable to a subshell, there's another way to do it besides setting the variable and then exporting it. On the command line, you can precede the name of the command with the assignment of as many variables as you want. For example: DBHOME=/unx2/data DBID=452 dbrun places the variables DBHOME and DBID, and their indicated values, into the environment of dbrun, and then dbrun gets executed. *These variables will not be known to the current shell; they're created only for the execution of dbrun.*" (Emphasis mine). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Oct 17 02:30:37 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 16 Oct 2012 22:30:37 -0400 (EDT) Subject: 14 years ago today.... In-Reply-To: <0E04BA77-C294-4DFC-8E03-E31296C51881@centergate.com> Message-ID: <9264965.31057.1350441037688.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rodney Joffe" > ... we lost Jon. > > http://www.ietf.org/rfc/rfc2468.txt Be liberal in what you accept, and conservative in what you send. I don't remember the timing; did Jon borrow that from Fidonet's "Be ye not overly annoying, nor too easily annoyed"? Or the other way 'round? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Wed Oct 17 03:06:12 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 16 Oct 2012 22:06:12 -0500 Subject: best way to create entropy? In-Reply-To: <507D2BCF.8070301@gmail.com> References: <507D2BCF.8070301@gmail.com> Message-ID: On 10/16/12, JC Dill wrote: It's interesting... though Lava lamps require heat to work, so not necessarily energy efficient. In theory, you shouldn't really need the lava lamp part. Just the digital camera part.. operate at a high ISO, say ISO 3000, dark background, and manual shutter and aperature controls, configured to achieve exposure with minimal light (E.g. a lowest possible usable exposure at the highest speed you can get), analyze, and discard the value of any pixels that statistically show as "hot" or "correlated" and capture the inherent CCD sensor noise due to unpredictability of electrons, which you maximized, without having to have any movement in the scene. > You might want to take a look at: > http://www.lavarnd.org/news/lavadiff.html > jc -- -JH From joseph at josephholsten.com Wed Oct 17 03:35:11 2012 From: joseph at josephholsten.com (Joseph Anthony Pasquale Holsten) Date: Wed, 17 Oct 2012 03:35:11 +0000 Subject: Please, talk me down. Message-ID: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally. But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? -- http://josephholsten.com From swmike at swm.pp.se Wed Oct 17 03:42:55 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 17 Oct 2012 05:42:55 +0200 (CEST) Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: On Wed, 17 Oct 2012, Joseph Anthony Pasquale Holsten wrote: > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start > with one for the AAAA record. Ah, no luck. Maybe you forgot the search > domain? Let's retry that DNS request with that tacked on. Failed again? > Meanwhile, lets simultaneously try for the AA record then. Repeat. You're describing normal behaviour. Why do you feel the behaviour you're seeing is a problem? Because you're not running IPv6, you're seeing twice the DNS traffic in some cases. Doing multiple lookups for everything in search domain is done for IPv4 as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From mike.lyon at gmail.com Wed Oct 17 03:43:53 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 16 Oct 2012 20:43:53 -0700 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <-6592624967355450967@unknownmsgid> Upgrade djbdns to support IPV6? Think there is a patch for it... -mike Sent from my iPhone On Oct 16, 2012, at 20:36, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally. > > But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. > > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? > -- > http://josephholsten.com From nanog at jima.tk Wed Oct 17 03:59:32 2012 From: nanog at jima.tk (Jima) Date: Tue, 16 Oct 2012 21:59:32 -0600 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <507E2D24.6070409@jima.tk> On 2012-10-16 21:35, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally. It sounds like this is a djbdns problem, not an IPv6 problem. FWIW, DJB's public take on IPv6 can be found here: http://cr.yp.to/djbdns/ipv6mess.html . Judging by the lack of updates in the past 10 years (OK, 10 years next month), I'm not certain whether his position has changed. (Granted, some of the ten-year-old facts have, so who knows.) Personally, I didn't agree with his perspective at the time, and I feel it's only gotten less valid over time. > But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. Are 2x the queries -- in exchange for future-proofing the network -- coming that close to overloading your DNS cache? You may want to re-evaluate the scalability of your cache. Or replace your DNS cache with something maintained in the last decade (I thought I was exaggerating, but the last changelog in 1.05 is 20010211), and deploy all your internal assets on IPv6 -- thus reducing the query load AND getting your systems ready for the future. > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? Go right ahead. But first, what company is this, so the rest of us can know to avoid doing business? ;-) Jima From randy at psg.com Wed Oct 17 04:20:29 2012 From: randy at psg.com (Randy Bush) Date: Tue, 16 Oct 2012 18:20:29 -1000 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: > First off, I'm using djbdns internally and it doesn't support AAAA > records. So we really aren't using it internally. if the clutch in my car is broken, should i stop using vehicles? dump djbdns or get some diehard to tell you how to fix it. randy From mysidia at gmail.com Wed Oct 17 04:33:16 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 16 Oct 2012 23:33:16 -0500 Subject: Detection of Rogue Access Points In-Reply-To: <1350267060.2856.133.camel@karl> References: <1350267060.2856.133.camel@karl> Message-ID: On 10/14/12, Karl Auer wrote: > No-one has said this yet, so I will - why are people working around your > normal network policies? This is often a sign of something lacking that > people need in their daily work. You can often reduce this sort of While that's no reason to stop looking for rogues... It's a good point that policy and planning there is a crucial element; more important than managing all network devices; or even having antivirus or firewalls. Because humans are a weak point -- every enterprise has them: there are ways the humans can be exploited unwittingly, humans might sometimes follow an improper procedure, the eventual occurrence of an incident related to human weakness may be inevitable. "Lacking something they need" is not likely. If it's really true that a forbidden thing is needed for their work -- they should be able to persuade their org's leadership to create a variance from the policy, or implement a solution. It's more likely the network user introduces rogue devices because (1) The rule wasn't written down.. E.g. It was actually an unwritten policy never carefully formulated into writing, that nobody may just plug in whatever network device wireless AP, 5 port switch, or Linksys router, even with a "good reason" to; the network users had no document to follow to explain mandatory steps required to introduce a new device. (2) The people don't know what the policy, standard, or directive actually is: They haven't been administered adequate training and been quizzed appropriately on the relevant policies, standards, and guidelines; their role with regard to the policy is not understood properly. (3) The organization hadn't made commitment to the pertinent IT policy clear. For example: The network user do not have high certainty that audit controls and procedures will be in place will detect their infraction and remove unauth'd equipment. If they are made certain a violation will be detected, and receive investigation, the rate of non-compliance could be expected to decrease. > Sometimes it's cheaper to give people what they want than to prevent > them taking it. Maybe at least consider that as an option. That depends on what 'they want'; and what regulations apply to the organization. The feds may force various organizations into saying no, even if network users want it, and the org. would prefer to allow it. If what the network users want is an unmanaged personal device on a corporate intranet, there are security considerations, which have a non-zero level of risk, that might be judged too high. Bandwidth and potentially firewall user licenses for i-devices to have continuous Facebook and Youtube access are not free. The possibility of required incident management for potential abuse cases. Possible SOX requirements to archive Twitter/Facebook "status update" message traffic.... etc. etc. > Regards, K. > Karl Auer (kauer at biplane.com.au) -- -JH From kauer at biplane.com.au Wed Oct 17 05:20:39 2012 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 17 Oct 2012 16:20:39 +1100 Subject: Please, talk me down. In-Reply-To: <507E2D24.6070409@jima.tk> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> <507E2D24.6070409@jima.tk> Message-ID: <1350451239.2958.63.camel@karl> On Tue, 2012-10-16 at 21:59 -0600, Jima wrote: > FWIW, DJB's public take on IPv6 can be found here: > http://cr.yp.to/djbdns/ipv6mess.html . After a quick read, it seems that that statement completely fails to consider dual stack as a transition mechanism. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From marka at isc.org Wed Oct 17 05:21:44 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 17 Oct 2012 16:21:44 +1100 Subject: Please, talk me down. In-Reply-To: Your message of "Wed, 17 Oct 2012 03:35:11 -0000." <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <20121017052144.66EE529EE784@drugs.dv.isc.org> In message <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7 at josephholsten.com>, Joseph Ant hony Pasquale Holsten writes: > I want to like IPv6. I do. But I'm seriously considering turning off > IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support AAAA > records. So we really aren't using it internally. djbdns doesn't support lots of things. > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start > with one for the AAAA record. Ah, no luck. Maybe you forgot the search > domain? Let's retry that DNS request with that tacked on. Failed again? > Meanwhile, lets simultaneously try for the AA record then. Repeat. It looks like your getaddrinfo implementation is a searching for AAAA records and then searching for A records. With a A record for name2 you get a query path like this. e.g. name1 AAAA -> NXDOMAIN name2 AAAA -> NODATA name3 AAAA -> NXDOMAIN name1 A -> NXDOMAIN name2 A -> DATA You could ask you vendor to implement a alternating search strategy. e.g. name1 AAAA -> NXDOMAIN name1 A -> NXDOMAIN name2 AAAA -> NODATA name2 A -> DATA Additionally you could get your vendor skip the A lookup on NXDOMAIN from AAAA. e.g. name1 AAAA -> NXDOMAIN name2 AAAA -> NODATA name2 A -> DATA > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me > off this ledge? > -- > http://josephholsten.com > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From alvarezp at alvarezp.ods.org Wed Oct 17 05:22:14 2012 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 16 Oct 2012 22:22:14 -0700 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: On Tue, 16 Oct 2012 20:35:11 -0700, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off > IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support AAAA > records. So we really aren't using it internally. > > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start > with one for the AAAA record. Ah, no luck. Maybe you forgot the search > domain? Let's retry that DNS request with that tacked on. Failed again? > Meanwhile, lets simultaneously try for the AA record then. Repeat. > > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me > off this ledge? You will eventually have to turn it on again, so you may run away from the problem that will catch you up anyway or, better, start tackling the problems, like fixing djbdns or replacing it with something that works. That's my way of seeing it. Good luck with it. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From tony at lavanauts.org Wed Oct 17 05:25:37 2012 From: tony at lavanauts.org (Antonio Querubin) Date: Tue, 16 Oct 2012 19:25:37 -1000 (HST) Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: On Wed, 17 Oct 2012, Joseph Anthony Pasquale Holsten wrote: > First off, I'm using djbdns internally and it doesn't support AAAA > records. So we really aren't using it internally. Sounds like a self-inflicted wound. You have alternatives. > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me > off this ledge? -- http://josephholsten.com You can stay on the ledge if you like. A lot of folks have already decided to move on... Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From froztbyte at froztbyte.net Wed Oct 17 05:25:58 2012 From: froztbyte at froztbyte.net (JP Viljoen) Date: Wed, 17 Oct 2012 07:25:58 +0200 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: On 17 Oct 2012, at 5:35 AM, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally. > > But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. ++ on what everyone else has said about this being a problem with the way you run your DNS infrastructure, instead of an actual IPv6 problem. Without reasons listed for why you use djbdns, I can't really adequately comment, but: on our net we're using unbound as caching DNS servers with pretty good success, and pdns with dynamic backends (the backends are custom in-house stuff) as our authoritative DNS. Short of issues now and then with the backends, it works pretty well. -J From johnl at iecc.com Wed Oct 17 14:25:36 2012 From: johnl at iecc.com (John Levine) Date: 17 Oct 2012 14:25:36 -0000 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <20121017142536.3374.qmail@joyce.lan> In article <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7 at josephholsten.com> you write: >I want to like IPv6. I do. But I'm seriously considering turning off >IPv6 support from our servers. > >First off, I'm using djbdns internally and it doesn't support AAAA >records. So we really aren't using it internally. I'm a long time djbdns user. But about a year ago, I switched from using dnscache to unbound for my cache, because it does useful stuff that dnscache doesn't do. I had a bunch of wacky local stuff configured into dnscache, like querying local servers for local-only domains, and substituting a local reject-all for some nasty outside domains, and it took about an hour to figure out how to do it all with unbound. I run it under daemontools. My authoritative servers are still tinydns, even though I do support IPv6. Since tinydns-data compiles stuff from a text source file, I have a perl script that translates lines with AAAA records in a normal format into the escape codes that tinydns uses for arbitrary record types. It's gross, but it works. So anyway, use unbound for your cache, no need to change away from tinydns unless you want to use DNSSEC, which it'll never support. -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From lstewart at superb.net Wed Oct 17 19:25:49 2012 From: lstewart at superb.net (Landon Stewart) Date: Wed, 17 Oct 2012 12:25:49 -0700 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? Message-ID: Hi Y'all Nanogites, We are changing over to PowerDNS from djbdns (tinydns) and I'm taking this opportunity to fix as much of our zone data as we can. Under tinydns things work fine despite these errors because tinydns lets you get away with stuff like this and still responds even though a zone might technically be broken because of it. The problem is that we have some zones that have records with the same hostname that have both a CNAME as well as an A record, MX record, SOA record and/or NS record. Is there an easy answer for what should be removed? I'm inclined to say that the CNAME should be removed in all these cases but I can't find any definitive information on this and after doing some tests it doesn't always seem straightforward. I've been reading various sites and information including RFC 1034 but it's difficult to decide what to do when it's already an issue. For example in RFC 1034 section 3.6.2 the use of CNAME's with NS and MX records is not permitted but other research shows this is widely used even though its technically invalid. IMHO it should have never happened in the first place (where an A record already exists a CNAME should not have been allowed to get added for example) but what can be done now that it's already an issue? In the case of the A,NS,MX,SOA and CNAME duplicates an example of how our old/current name server's responses are: (*note: not all of this is real data, customer zones have been obfuscated)* * * # dig @ns1.superb.net +nocmd mail.customerzone.com A +noques +answer ;; ANSWER SECTION: mail.customerzone.com. 14342 IN CNAME mail.superb.net. mail.customerzone.com. 86342 IN A xx.xx.246.9 # dig @ns1.superb.net +nocmd superbcolo.biz NS +noques +answer ;; ANSWER SECTION: superbcolo.biz. 86400 IN NS ns1.superb.net. superbcolo.biz. 86400 IN NS ns2.superb.net. superbcolo.biz. 86400 IN NS ns3.superb.net. superbcolo.biz. 86400 IN CNAME superbenterprise.net. # dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer ;; ANSWER SECTION: superbcolo.biz. 86400 IN MX 10 superbcolo.biz. superbcolo.biz. 86400 IN CNAME superbenterprise.net. dig @ns1.superb.net +nocmd customerzone2.com SOA +noques +answer ;; ANSWER SECTION: customerzone2.com. 86400 IN CNAME superbenterprise.net. customerzone2.com. 86400 IN SOA ns1.superb.net. hostmaster.superb.net. 1350501302 0 0 0 0 Should the CNAME just get nuked in all of these cases? -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From asullivan at dyn.com Wed Oct 17 19:41:24 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 17 Oct 2012 15:41:24 -0400 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: <20121017194124.GB18864@dyn.com> On Wed, Oct 17, 2012 at 12:25:49PM -0700, Landon Stewart wrote: > hostname that have both a CNAME as well as an A record, MX record, SOA > record and/or NS record. Is there an easy answer for what should be > removed? "You should remove the one that you don't need." A CNAME may not be at the same owner name as any other RR. If you need an alias, then you want a CNAME. If you need some other record, you need not to have a CNAME. If you think about what a CNAME is, it is obvious that it can't exist at the same name as any other RR, because it says "this name is actually that name over there". > Should the CNAME just get nuked in all of these cases? Probably. A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From bill at herrin.us Wed Oct 17 20:00:49 2012 From: bill at herrin.us (William Herrin) Date: Wed, 17 Oct 2012 16:00:49 -0400 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: On Wed, Oct 17, 2012 at 3:25 PM, Landon Stewart wrote: > The problem is that we have some zones that have records with the same > hostname that have both a CNAME as well as an A record, MX record, SOA > record and/or NS record. Is there an easy answer for what should be > removed? I'm inclined to say that the CNAME should be removed in all these > cases but I can't find any definitive information on this and after doing > some tests it doesn't always seem straightforward. If you have a CNAME record for a particular name, you should not have any other record of any type for that same name. Which you should remove depends on the details of the particular circumstance. If you really mean "identical to that other name with respect to all records and record types" then there's nothing inherently wrong with the CNAME. If you don't, then you shouldn't use a CNAME there. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nicolai-nanog at chocolatine.org Wed Oct 17 20:44:23 2012 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Wed, 17 Oct 2012 15:44:23 -0500 Subject: Please, talk me down. In-Reply-To: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <20121017204423.GA30547@vectra.student.iastate.edu> On Wed, Oct 17, 2012 at 03:35:11AM +0000, Joseph Anthony Pasquale Holsten wrote: > First off, I'm using djbdns internally and it doesn't support AAAA > records. So we really aren't using it internally. I assume you mean stock djbdns doesn't support ip6, because it does indeed support AAAA records. I use both dnscache and tinydns from djbdns and AAAA records work fine for me. Note: I'm not using Felix von Leitner's ip6 patch. $ dig aaaa chocolatine.org +short 2610:130:103:e00:201:2ff:fe45:8308 Resolver is dnscache, authoritate server is tinydns. No problem. I think the problem you're experiencing, if there is one, is not related to either djbdns or ip6. Nicolai From jtk at cymru.com Wed Oct 17 22:08:55 2012 From: jtk at cymru.com (John Kristoff) Date: Wed, 17 Oct 2012 17:08:55 -0500 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <20121017170855.60f736a9@localhost> On Sun, 14 Oct 2012 16:59:12 -0400 Jonathan Rogers wrote: > I'm looking for innovative ideas on how to find such a rogue device, Here is an old post that describes some techniques, while date, should still be at least partially effective and help form part of a more comprehensive solution: John From mysidia at gmail.com Thu Oct 18 02:45:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 17 Oct 2012 21:45:09 -0500 Subject: Please, talk me down. In-Reply-To: References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: On 10/16/12, Randy Bush wrote: >> First off, I'm using djbdns internally and it doesn't support AAAA >> records. So we really aren't using it internally. > if the clutch in my car is broken, should i stop using vehicles? > dump djbdns or get some diehard to tell you how to fix it. Ah, but the clutch is not actually broken; it works perfectly, and it is a very robust clutch, not likely to break, it's just that the car was designed, so you need a wrench with you while at all times while driving, to actuate the clutch, and you need a screwdriver onhand as well to adjust gears. They have a raw record format, that allows you to enter a raw record into your tinydns data file, containing anything, including AAAA data. However, djbdns also lacks support for DNSSEC validation. the stock package 1.05, when installed on a 64-bit OS, contained an unpatched security vulnerability. The car was also designed with no electric ignition switch, and no headlights. You want to start your car, you need a manual crank. It's "good enough"; but probably the time comes soon to retire it. Electronic ignitions and headlights became the 'standard' a long time ago, but the car design was never improved to include the features (not necessarily an easy feat) -- meanwhile, the person in charge of maintaining the design; spent many hours writing essays about the problem of light pollution caused by headlights, insisting that road lights instead would be better, and calling up issues about the extra weight and space required for batteries, danger of batteries leaking, or failing, leaving motorists stranded, etc, thus spending time not updating the design to incorporate beneficial, new standards. > randy -- -JH From jcurran at arin.net Thu Oct 18 06:41:42 2012 From: jcurran at arin.net (John Curran) Date: Thu, 18 Oct 2012 06:41:42 +0000 Subject: NRO NC Election now open to registered NANOG attendees !! References: <507EB813.6060107@arin.net> Message-ID: <10F0AFEE-CC53-49D8-86D8-1534E513B49C@corp.arin.net> NANOG Community - The NRO NC (also known as the ASO AC) Election is open to NANOG meeting attendees; your participation will help select representatives from this region who will work on number policy coordination on a global basis, as well help in the selection of representatives to various ICANN bodies, including the ICANN Board. Please take a moment to review the attached materials and vote when you have a moment. Thank you! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] NRO NC Election Opens Today Date: October 17, 2012 9:52:19 AM EDT To: > The polls are now open for the election to fill the one open seat on the Number Resource Organization Number Council (NRO NC) from the ARIN region. The polls close at 5:00 PM ET, 24 October. Brief candidate biographies and a link to submit or view statements of support are posted on ARIN's website at: https://www.arin.net/app/election/ Designated Member Representatives (DMRs), NANOG Meeting attendees, and ARIN Meeting attendees are eligible to vote. NANOG or ARIN attendees must have registered for their meeting by 10 October 2012 to be eligible to vote. To vote, visit ARIN Election Headquarters and click on the Vote button. https://www.arin.net/app/election/ You can read instructions on how to cast your vote at: https://www.arin.net/participate/elections/instructions.html#vote Voters must cast and confirm their ballots by 5:00 PM ET, 24 October. A compilation of Candidate questionnaire responses in PDF is available at: https://www.arin.net/participate/elections/candidate_bios.pdf If you have any questions about voting or encounter problems with the system, please contact ARIN Member Services at info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From dot at dotat.at Thu Oct 18 08:56:56 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 18 Oct 2012 09:56:56 +0100 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: Landon Stewart wrote: > > The problem is that we have some zones that have records with the same > hostname that have both a CNAME as well as an A record, MX record, SOA > record and/or NS record. Is there an easy answer for what should be > removed? You can never have a CNAME record at a zone apex, because a zone apex has to have SOA and NS RRs and a CNAME can never coexist with other RRs. So those cases are simple. If the misconfigured CNAME is not at a zone apex then you have to decide whether the CNAME or the other records are correct - do you get the right result from the DNS when deleting one or the other? If it works either way then your decision mainly depends on how frequently the target address changes and if you need to make co-ordinated changes across many zones - if so then a CNAME tends to be preferable. But you probably have to have a workaround for A records at zone apexes in which case that tooling probably removes CNAMEs' advantage and you might as well use A records everywhere. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jason at jasonantman.com Thu Oct 18 13:15:18 2012 From: jason at jasonantman.com (Jason Antman) Date: Thu, 18 Oct 2012 09:15:18 -0400 Subject: Detection of Rogue Access Points In-Reply-To: References: Message-ID: <508000E6.8060003@jasonantman.com> Some very good points were made in the thread. I've dealt with this problem a few times. I'll admit, the only perfect solution I've found is to install a Internet-only (its own router interface or VLAN, firewalled off from everything else) AP for people to use because, frankly, consumer-grade APs are just too easy to install. On the technical side, to reiterate what others have suggested: - Scan MACs from the router ARP table or DHCP logs, flag anything from a common wireless vendor - Script to pull new DHCP leases, check each with NMAP, alert on anything suspicious - Port security, if you can - Scanning the air The only *real* way to detect rogue APs is to actually scan the airwaves. There's a bunch of vendors who sell hardware/software solutions for this, and there are also a lot of APs that support it, especially if you can deal with something manual. Ubiquiti Networks sells some sub-$100 USD access points that do a nice "site survey" as well as a spectrum analyzer, and could be used to get this info. Of course that becomes more of a burden if there are multiple other wireless networks within range of you (should be fine if your branches are on their own property, could be a problem if they're in commercial/professional buildings). I don't know if the Ubiquiti products are easily scriptable, but they *do* offer a SDK and with some amount of effort, it would probably be possible to pull this data via a script. The times that I've done this, we've just grabbed a bunch of decommissioned corporate laptops with wireless & wired ethernet interfaces, put Linux on them, and written a script that scans for visible wireless networks every 5-30 minutes, and emails any changes to us. Laptops were configured for DHCP, and just plugged in and nestled somewhere in the wiring closet. Net cost $0 (well maybe some patch cables), and worked fine for us. -Jason On 10/14/2012 04:59 PM, Jonathan Rogers wrote: > Gentlemen, > > An issue has come up in my organization recently with rogue access points. > So far it has manifested itself two ways: > > 1. A WAP that was set up specifically to be transparent and provided > unprotected wireless access to our network. > > 2. A consumer-grade wireless router that was plugged in and "just worked" > because it got an address from DHCP and then handed out addresses on its > own little network. > > These are at remote sites that are on their own subnets (10.100.x.0/24; > about 130 of them so far). Each site has a decent Cisco router at the > demarc that we control. The edge is relatively low-quality managed layer 2 > switches that we could turn off ports on if we needed to, but we have to > know where to look, first. > > I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. With situation #2 we > may be able to detect NAT going on that should not be there. Situation #1 > is much more difficult, although I've seen some research material on how > frames that originate from 802.11 networks look different from regular > ethernet frames. Installation of an advanced monitoring device at each site > is not really practical, but we may be able to run some software on a > Windows PC in each office. One idea put forth was checking for NTP traffic > that was not going to our authorized NTP server, but NTP isn't necessarily > turned on by default, especially on consumer-grade hardware. > > Any ideas? > > Thank you for your time, > > Jonathan Rogers From quantumfoam at gmail.com Thu Oct 18 14:00:27 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Thu, 18 Oct 2012 10:00:27 -0400 Subject: Detection of Rogue Access Points In-Reply-To: <508000E6.8060003@jasonantman.com> References: <508000E6.8060003@jasonantman.com> Message-ID: I like the idea of looking at the ARP table periodically, but this presents some possible issues for us. The edge routers at our remote sites are Cisco 1841 devices, typically with either an MPLS T1 or a Public T1 (connected via an IAD owned by Centurylink; router to router, so dumb). Aside from manually logging in to those individual routers (all 140 or so of them) and checking them on a schedule, can anyone think of a good way to capture that information automatically? If I had to I could probably come up with a script to log in to them and scrape the info then process it but...eww. Another possible option (although costly) is installing a Ruckus device at each location; we have a Ruckus infrastructure at our HDQ and it works great (almost too good, it's super sensitive) at picking up rogues. A Ruckus WAP could talk to our ZoneDirector appliance and do that for us at each site, I think, but it may be difficult to justify the cost. --JR On Thu, Oct 18, 2012 at 9:15 AM, Jason Antman wrote: > Some very good points were made in the thread. I've dealt with this > problem a few times. I'll admit, the only perfect solution I've found is to > install a Internet-only (its own router interface or VLAN, firewalled off > from everything else) AP for people to use because, frankly, consumer-grade > APs are just too easy to install. > > On the technical side, to reiterate what others have suggested: > - Scan MACs from the router ARP table or DHCP logs, flag anything from a > common wireless vendor > - Script to pull new DHCP leases, check each with NMAP, alert on anything > suspicious > - Port security, if you can > - Scanning the air > > The only *real* way to detect rogue APs is to actually scan the airwaves. > There's a bunch of vendors who sell hardware/software solutions for this, > and there are also a lot of APs that support it, especially if you can deal > with something manual. Ubiquiti Networks sells some sub-$100 USD access > points that do a nice "site survey" as well as a spectrum analyzer, and > could be used to get this info. Of course that becomes more of a burden if > there are multiple other wireless networks within range of you (should be > fine if your branches are on their own property, could be a problem if > they're in commercial/professional buildings). I don't know if the Ubiquiti > products are easily scriptable, but they *do* offer a SDK and with some > amount of effort, it would probably be possible to pull this data via a > script. > > The times that I've done this, we've just grabbed a bunch of > decommissioned corporate laptops with wireless & wired ethernet interfaces, > put Linux on them, and written a script that scans for visible wireless > networks every 5-30 minutes, and emails any changes to us. Laptops were > configured for DHCP, and just plugged in and nestled somewhere in the > wiring closet. Net cost $0 (well maybe some patch cables), and worked fine > for us. > > -Jason > > > On 10/14/2012 04:59 PM, Jonathan Rogers wrote: > >> Gentlemen, >> >> An issue has come up in my organization recently with rogue access points. >> So far it has manifested itself two ways: >> >> 1. A WAP that was set up specifically to be transparent and provided >> unprotected wireless access to our network. >> >> 2. A consumer-grade wireless router that was plugged in and "just worked" >> because it got an address from DHCP and then handed out addresses on its >> own little network. >> >> These are at remote sites that are on their own subnets (10.100.x.0/24; >> about 130 of them so far). Each site has a decent Cisco router at the >> demarc that we control. The edge is relatively low-quality managed layer 2 >> switches that we could turn off ports on if we needed to, but we have to >> know where to look, first. >> >> I'm looking for innovative ideas on how to find such a rogue device, >> ideally as soon as it is plugged in to the network. With situation #2 we >> may be able to detect NAT going on that should not be there. Situation #1 >> is much more difficult, although I've seen some research material on how >> frames that originate from 802.11 networks look different from regular >> ethernet frames. Installation of an advanced monitoring device at each >> site >> is not really practical, but we may be able to run some software on a >> Windows PC in each office. One idea put forth was checking for NTP traffic >> that was not going to our authorized NTP server, but NTP isn't necessarily >> turned on by default, especially on consumer-grade hardware. >> >> Any ideas? >> >> Thank you for your time, >> >> Jonathan Rogers >> > > > From ray at oneunified.net Thu Oct 18 14:10:07 2012 From: ray at oneunified.net (Raymond Burkholder) Date: Thu, 18 Oct 2012 11:10:07 -0300 Subject: Detection of Rogue Access Points In-Reply-To: References: <508000E6.8060003@jasonantman.com> Message-ID: <0b5201cdad3a$47f59e40$d7e0dac0$@oneunified.net> > I like the idea of looking at the ARP table periodically, but this presents > some possible issues for us. The edge routers at our remote sites are Cisco > 1841 devices, typically with either an MPLS T1 or a Public T1 (connected > via an IAD owned by Centurylink; router to router, so dumb). Aside from > manually logging in to those individual routers (all 140 or so of them) and > checking them on a schedule, can anyone think of a good way to capture that > information automatically? If I had to I could probably come up with a > script to log in to them and scrape the info then process it but...eww. NetDisco knows how to scan networks for mac addresses, arp addresses, ip addresses, etc. It keeps track of deltas. It may have be able to email deltas or something similar. Or run a query against the database, as I seem to recall it seems to hold historical data. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From joe at nethead.com Thu Oct 18 14:12:31 2012 From: joe at nethead.com (Joe Hamelin) Date: Thu, 18 Oct 2012 07:12:31 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <508000E6.8060003@jasonantman.com> Message-ID: On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers wrote: > I like the idea of looking at the ARP table periodically, but this presents > some possible issues for us. Is it just WAPs that you are worried about or any rouge device at the remote sites? If you're doing medical data then I would think that any non-company device would be suspect. If that is the case then ARP scraping is the better way. Basically you need an inventory of what is at the sites. This you should already have and if you don't, that is your first step. A bit of perl and expect scripting would get you a long way to your goal. Like I mentioned before, if you don't have the time/talent to script the task, call out for a coder-for-hire. I feel that concentration just on WAPs is missing the bigger issue. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From tony at swalter.com Thu Oct 18 14:28:46 2012 From: tony at swalter.com (Tony Patti) Date: Thu, 18 Oct 2012 10:28:46 -0400 Subject: Google opens Web Window on their Data Centers Message-ID: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> http://www.google.com/about/datacenters/gallery/#/ "Where the Internet lives - Take a look inside Google's high-tech data centers" showed up as an article in the local _Philadelphia_Inquirer_ newspaper this morning. http://www.philly.com/philly/business/174685071.html Because of prior Data Center and Google discussions on NANOG, am hoping this is interesting to others. Tony Patti CIO S. Walter Packaging From derek at derekivey.com Thu Oct 18 14:33:44 2012 From: derek at derekivey.com (Derek Ivey) Date: Thu, 18 Oct 2012 10:33:44 -0400 Subject: Google opens Web Window on their Data Centers In-Reply-To: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> References: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> Message-ID: <86281B7F-5A44-4FC7-B91D-59263CC4222D@derekivey.com> I saw that yesterday. I also enjoyed looking at the inside of their datacenter on Google Street view. https://maps.google.com/maps?hl=en&ll=35.898532,-81.545817&spn=0.004806,0.010568&sll=35.900197,-81.547024&layer=c&cid=7373938251588581469&panoid=2A5KnxdctVfIXT0qFF5Z6Q&cbp=13,356.72,,0,2.73&gl=US&t=m&cbll=35.898546,-81.547919&z=17 Derek On Oct 18, 2012, at 10:28 AM, "Tony Patti" wrote: > > http://www.google.com/about/datacenters/gallery/#/ > > "Where the Internet lives - Take a look inside Google's high-tech data > centers" > > showed up as an article in the local _Philadelphia_Inquirer_ newspaper this > morning. > > http://www.philly.com/philly/business/174685071.html > > Because of prior Data Center and Google discussions on NANOG, am hoping this > is interesting to others. > > Tony Patti > CIO > S. Walter Packaging > > > > > > > From darrenoc at outlook.com Wed Oct 17 17:59:09 2012 From: darrenoc at outlook.com (Darren O'Connor) Date: Wed, 17 Oct 2012 18:59:09 +0100 Subject: 169.254.0.0/16 Message-ID: I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space. RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address. So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it? Thanks Darren From jra at baylink.com Thu Oct 18 15:12:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 18 Oct 2012 11:12:08 -0400 (EDT) Subject: WW: First round .web application IODesign sues ICANN Message-ID: <9855119.31381.1350573128082.JavaMail.root@benjamin.baylink.com> http://domainincite.com/10783-original-web-gtld-applicant-sues-icann Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From msa at latt.net Thu Oct 18 15:18:56 2012 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 18 Oct 2012 11:18:56 -0400 Subject: 169.254.0.0/16 In-Reply-To: References: Message-ID: <20121018151856.GD3768@puck.nether.net> On Wed, Oct 17, 2012 at 06:59:09PM +0100, Darren O'Connor wrote: > I've just set up a vpn tunnel to Amazon's AWS and as part of the config > they required me to configure to /30 tunnels using addressing from the > 169.254.0.0/16 space. Yeah, they do that for Direct Connect. > RFC3927 basically says that this address should only be used as a temp > measure until the interface has a proper private or public address. So? :) > So what's the consensus then? Is their a problem using this space as > link-local address for routers here and there (I mean we have 65K > addresses wasted in this block) or is it a strict no-no? And if no, why > is Amazon using it? RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts. Since these networks are all isolated, I don't see a great deal of harm in it (probably less than overlapping more commonly used private blocks.) --msa From darrenoc at outlook.com Thu Oct 18 15:22:22 2012 From: darrenoc at outlook.com (Darren O'Connor) Date: Thu, 18 Oct 2012 16:22:22 +0100 Subject: 169.254.0.0/16 In-Reply-To: <20121018151856.GD3768@puck.nether.net> References: , <20121018151856.GD3768@puck.nether.net> Message-ID: I would agree. I don't see it as a problem using it, but I was mainly wondering about what other people thought of using it. And yes, it's nice to use as people are using RFC1918 addresses in their networks and you can be sure that 169.254.0.0/16 isn't used. At least until people do start using it and then you have the same overlapping problem again > Date: Thu, 18 Oct 2012 11:18:56 -0400 > From: msa at latt.net > To: darrenoc at outlook.com > CC: nanog at nanog.org > Subject: Re: 169.254.0.0/16 > > On Wed, Oct 17, 2012 at 06:59:09PM +0100, Darren O'Connor wrote: > > I've just set up a vpn tunnel to Amazon's AWS and as part of the config > > they required me to configure to /30 tunnels using addressing from the > > 169.254.0.0/16 space. > > Yeah, they do that for Direct Connect. > > > RFC3927 basically says that this address should only be used as a temp > > measure until the interface has a proper private or public address. > > So? :) > > > So what's the consensus then? Is their a problem using this space as > > link-local address for routers here and there (I mean we have 65K > > addresses wasted in this block) or is it a strict no-no? And if no, why > > is Amazon using it? > > RFCs are just paper. As for why they use it.. the common private > use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use > internally in their customers networks. This is probably the easiest > way to avoid addressing conflicts. > > Since these networks are all isolated, I don't see a great deal > of harm in it (probably less than overlapping more commonly used private > blocks.) > > --msa From morrowc.lists at gmail.com Thu Oct 18 15:25:16 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Oct 2012 11:25:16 -0400 Subject: 169.254.0.0/16 In-Reply-To: <20121018151856.GD3768@puck.nether.net> References: <20121018151856.GD3768@puck.nether.net> Message-ID: On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas wrote: > RFCs are just paper. As for why they use it.. the common private > use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use > internally in their customers networks. This is probably the easiest > way to avoid addressing conflicts. > but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10 :) From jra at baylink.com Thu Oct 18 15:34:06 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 18 Oct 2012 11:34:06 -0400 (EDT) Subject: WW: First round .web application IODesign sues ICANN In-Reply-To: <9855119.31381.1350573128082.JavaMail.root@benjamin.baylink.com> Message-ID: <26164246.31387.1350574446942.JavaMail.root@benjamin.baylink.com> ".web applicant" ----- Original Message ----- > From: "Jay Ashworth" > http://domainincite.com/10783-original-web-gtld-applicant-sues-icann -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From dot at dotat.at Thu Oct 18 15:34:58 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 18 Oct 2012 16:34:58 +0100 Subject: Google opens Web Window on their Data Centers In-Reply-To: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> References: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> Message-ID: Tony Patti wrote: > > http://www.google.com/about/datacenters/gallery/#/ Also worth seeing is this article which explains how their hot aisles work: http://www.datacenterknowledge.com/archives/2012/10/17/how-google-cools-its-armada-of-servers/ And this longer and fluffier piece in Wired: http://www.wired.com/wiredenterprise/2012/10/ff-inside-google-data-center/all/ Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jaw+nanog01 at tcp4me.com Thu Oct 18 15:49:31 2012 From: jaw+nanog01 at tcp4me.com (jeff weisberg) Date: Thu, 18 Oct 2012 11:49:31 -0400 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: <6846792E-E239-4693-AB5E-38ACBB704086@tcp4me.com> On 17 Oct 2012, at 15:25, Landon Stewart wrote: > The problem is that we have some zones that have records with the same > hostname that have both a CNAME as well as an A record, MX record, SOA > record and/or NS record. > # dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer > ;; ANSWER SECTION: > superbcolo.biz. 86400 IN MX 10 superbcolo.biz. > superbcolo.biz. 86400 IN CNAME superbenterprise.net. > Should the CNAME just get nuked in all of these cases? no. if you nuke them, you'll break something. you're going to need to go through them all one by one, figure out why the CNAME is there, what it is doing, and how to change it. for example, "superbcolo.biz" has an MX and CNAME. the CNAME points to "superbenterprise.net", which has an A, and that A has a web server running. it may be "wrong", but http://superbcolo.biz works. so in this case, you'd need to replace the CNAME with the A. otherwise, you're breaking someone's website. which might be bad. From jcdill.lists at gmail.com Thu Oct 18 15:51:03 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 18 Oct 2012 08:51:03 -0700 Subject: best way to create entropy? In-Reply-To: References: <507D2BCF.8070301@gmail.com> Message-ID: <50802567.8090106@gmail.com> On 16/10/12 8:06 PM, Jimmy Hess wrote: > On 10/16/12, JC Dill wrote: >> You might want to take a look at: >> http://www.lavarnd.org/news/lavadiff.html > It's interesting... though Lava lamps require heat to work, so not > necessarily energy efficient. In theory, you shouldn't really need > the lava lamp part. Just the digital camera part.. You didn't read the whole page. On the right side: our LavaRnd^tm Spelled *LavaRnd*, mixed case with 2 a's Reference implementation uses lens-capped digital cameras to produce random numbers. Directly produces cryptographically sound random numbers. A single camera image frame can typically produce between 340 and 1420 bytes bytes of random numbers. jc From quantumfoam at gmail.com Thu Oct 18 17:05:14 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Thu, 18 Oct 2012 13:05:14 -0400 Subject: Detection of Rogue Access Points In-Reply-To: <50802EC9.8020002@bootc.net> References: <508000E6.8060003@jasonantman.com> <50802EC9.8020002@bootc.net> Message-ID: I, uh...don't actually know how to do that. I've not done very much with SNMP other than working with power management devices. If someone could direct me to a good tutorial, that would be much appreciated. --JR On Thu, Oct 18, 2012 at 12:31 PM, Chris Boot wrote: > On 18/10/12 15:12, Joe Hamelin wrote: > >> On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers >> wrote: >> >> I like the idea of looking at the ARP table periodically, but this >>> presents >>> some possible issues for us. >>> >> >> Is it just WAPs that you are worried about or any rouge device at the >> remote sites? If you're doing medical data then I would think that any >> non-company device would be suspect. If that is the case then ARP >> scraping >> is the better way. Basically you need an inventory of what is at the >> sites. This you should already have and if you don't, that is your first >> step. >> >> A bit of perl and expect scripting would get you a long way to your goal. >> Like I mentioned before, if you don't have the time/talent to script the >> task, call out for a coder-for-hire. >> > > You should be able to get the ARP table off a router using SNMP, which > would be much cleaner than using expect to login to a router's management > interface... > > HTH, > Chris > > From lstewart at superb.net Thu Oct 18 17:39:28 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 18 Oct 2012 10:39:28 -0700 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: <6846792E-E239-4693-AB5E-38ACBB704086@tcp4me.com> References: <6846792E-E239-4693-AB5E-38ACBB704086@tcp4me.com> Message-ID: Thanks for all your replies. I'm going to have go through these records and resolve these issues by evaluating them one by one since there doesn't seem to be any quick and dirty rules to any of them. On 18 October 2012 08:49, jeff weisberg wrote: > > On 17 Oct 2012, at 15:25, Landon Stewart wrote: > > The problem is that we have some zones that have records with the same >> hostname that have both a CNAME as well as an A record, MX record, SOA >> record and/or NS record. >> > > # dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer >> ;; ANSWER SECTION: >> superbcolo.biz. 86400 IN MX 10 superbcolo.biz. >> superbcolo.biz. 86400 IN CNAME superbenterprise.net. >> > > > > Should the CNAME just get nuked in all of these cases? >> > > > no. > > if you nuke them, you'll break something. > > you're going to need to go through them all one by one, figure out > why the CNAME is there, what it is doing, and how to change it. > > > for example, "superbcolo.biz" has an MX and CNAME. the CNAME > points to "superbenterprise.net", which has an A, and that A > has a web server running. > > it may be "wrong", but http://superbcolo.biz works. so in this > case, you'd need to replace the CNAME with the A. otherwise, > you're breaking someone's website. which might be bad. > > > > -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From hvgeekwtrvl at gmail.com Thu Oct 18 18:21:45 2012 From: hvgeekwtrvl at gmail.com (james machado) Date: Thu, 18 Oct 2012 11:21:45 -0700 Subject: Detection of Rogue Access Points In-Reply-To: References: <508000E6.8060003@jasonantman.com> Message-ID: On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers wrote: > I like the idea of looking at the ARP table periodically, but this presents > some possible issues for us. The edge routers at our remote sites are Cisco > 1841 devices, typically with either an MPLS T1 or a Public T1 (connected > via an IAD owned by Centurylink; router to router, so dumb). Aside from > manually logging in to those individual routers (all 140 or so of them) and > checking them on a schedule, can anyone think of a good way to capture that > information automatically? If I had to I could probably come up with a > script to log in to them and scrape the info then process it but...eww. > quite a few people have leveraged RANCID (http://www.shrubbery.net/rancid/) for doing stuff like this. it is made to pull configs from routers on a cycle and produces text files that can be worked with. you can use the tools that are there to pull specific information, such as arp tables, and then process the resultant files with your scripting language of choice. check the mail list for examples of this kind of thing. > Another possible option (although costly) is installing a Ruckus device at > each location; we have a Ruckus infrastructure at our HDQ and it works > great (almost too good, it's super sensitive) at picking up rogues. A > Ruckus WAP could talk to our ZoneDirector appliance and do that for us at > each site, I think, but it may be difficult to justify the cost. > > --JR > james From Sean.Pedersen at usairways.com Thu Oct 18 19:57:16 2012 From: Sean.Pedersen at usairways.com (Pedersen, Sean) Date: Thu, 18 Oct 2012 12:57:16 -0700 Subject: Semi-automated L3 interface DNS records Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. From regnauld at nsrc.org Thu Oct 18 20:10:46 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 18 Oct 2012 22:10:46 +0200 Subject: Semi-automated L3 interface DNS records In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <20121018201046.GB83649@macbook.bluepipe.net> Pedersen, Sean (Sean.Pedersen) writes: > Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? Hi Sean, Part of Netdot's (Network Documentation Tool - netdot.uoregon.edu) functionality is to produce automated DNS zone exports based on the IPAM information it manages, including L3 devices and their interfaces. > We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. Writing the scripts isn't too difficult, but as you write, you still need to detect dead entries, differentiate between an interface disappearing because it was deprovisioned, and the sudden disappearance of a large number of IFs due to a script failing (is 1 dead entry acceptable ? 10 ? 1000 ?) Cheers, Phil From regnauld at nsrc.org Thu Oct 18 20:21:57 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 18 Oct 2012 22:21:57 +0200 Subject: Detection of Rogue Access Points In-Reply-To: <0b5201cdad3a$47f59e40$d7e0dac0$@oneunified.net> Message-ID: <20121018202157.GD83649@macbook.bluepipe.net> Raymond Burkholder (ray) writes: > > NetDisco knows how to scan networks for mac addresses, arp addresses, ip > addresses, etc. It keeps track of deltas. It may have be able to email > deltas or something similar. Or run a query against the database, as I > seem to recall it seems to hold historical data. Yes, NetDisco will do this, and it has query interface for looking up MAC <-> associations, and where they were last seen. Netdot (netdot.uoregon.edu, just mentioned it in an earlier mail) also offers this functionality, and stores the information in the database for querying/searching. Jonathan Rogers (quantumfoam) writes: > I, uh...don't actually know how to do that. I've not done very much with > SNMP other than working with power management devices. If someone could > direct me to a good tutorial, that would be much appreciated. It's probably easier to use one of the tools mentioned than to start writing your own. To do that, you'd have to retrieve the L2 forwarding table from switches, and the ARP tables from L3 devices. You have to query all active devices regularly and build/update your DB from that. There are tools such as SNMP::Info http://search.cpan.org/~maxb/SNMP-Info-2.01 that make this easier, but still some amount of coding would be required. It's then a matter of querying the DB, and looking for the MAC addresses of suspected rogue devices, if they keep on showing up (you will see many one-times that don't reappear, which also grows the DB significantly over time). Phil From quantumfoam at gmail.com Thu Oct 18 21:43:55 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Thu, 18 Oct 2012 17:43:55 -0400 Subject: Detection of Rogue Access Points In-Reply-To: <20121018202157.GD83649@macbook.bluepipe.net> References: <0b5201cdad3a$47f59e40$d7e0dac0$@oneunified.net> <20121018202157.GD83649@macbook.bluepipe.net> Message-ID: Nevermind, it appears SNMP is turned off on our routers and I do not have control over that. I can at least present this as a possible option to the person that does. Thank you very much for your suggestions, everyone. I'm so glad I joined this list; I've learned so much and it's great to talk to people who like to share their knowledge and experience. --JR On Thu, Oct 18, 2012 at 4:21 PM, Phil Regnauld wrote: > Raymond Burkholder (ray) writes: > > > > NetDisco knows how to scan networks for mac addresses, arp addresses, ip > > addresses, etc. It keeps track of deltas. It may have be able to email > > deltas or something similar. Or run a query against the database, as I > > seem to recall it seems to hold historical data. > > Yes, NetDisco will do this, and it has query interface for looking > up MAC <-> associations, and where they were last seen. > > Netdot (netdot.uoregon.edu, just mentioned it in an earlier mail) > also > offers this functionality, and stores the information in the > database for > querying/searching. > > Jonathan Rogers (quantumfoam) writes: > > I, uh...don't actually know how to do that. I've not done very much with > > SNMP other than working with power management devices. If someone could > > direct me to a good tutorial, that would be much appreciated. > > It's probably easier to use one of the tools mentioned than to > start > writing your own. To do that, you'd have to retrieve the L2 > forwarding table from switches, and the ARP tables from L3 devices. > You have to query all active devices regularly and build/update > your DB > from that. There are tools such as SNMP::Info > http://search.cpan.org/~maxb/SNMP-Info-2.01 that make this easier, > but still some amount of coding would be required. > > It's then a matter of querying the DB, and looking for the MAC > addresses > of suspected rogue devices, if they keep on showing up (you will > see many > one-times that don't reappear, which also grows the DB > significantly over > time). > > Phil > From eric at opticfusion.net Thu Oct 18 21:47:01 2012 From: eric at opticfusion.net (Eric Stockwell) Date: Thu, 18 Oct 2012 14:47:01 -0700 Subject: Semi-automated L3 interface DNS records In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <508078D5.3090508@opticfusion.net> We use a customized version of this: https://gist.github.com/778830 On 10/18/2012 12:57 PM, Pedersen, Sean wrote: > Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? > > We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. From ras at e-gerbil.net Thu Oct 18 22:44:49 2012 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 18 Oct 2012 17:44:49 -0500 Subject: Semi-automated L3 interface DNS records In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <20121018224449.GN65604@gerbil.cluepon.net> On Thu, Oct 18, 2012 at 12:57:16PM -0700, Pedersen, Sean wrote: > Does anyone out there have any experience with a script, tool or appliance > that would help manage the creation and maintenance of DNS records for > Layer 3 interfaces on routers and switches? http://cluepon.net/ras/generate_dnsptr_generic_php A relatively simple example using php, with the net-snmp module and Net_IPv4 from PEAR. For extra bonus points, it parses your BGP state and uses any neighbor ASNs it finds for the remote side of your /30 or /31s, and it resolves point-to-point SVIs to physical ports by checking against the vlan tables. The later part was only tested on Cisco 6500s, and I haven't touched that code (or those boxes) in many many years, so no guarantees about using it on anything else. :) Out of date DNS PTRs in traceroute make baby jesus cry, so please use copiously. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From drew.linsalata at gmail.com Fri Oct 19 01:05:51 2012 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 18 Oct 2012 21:05:51 -0400 Subject: Anyone from Lightower (AS46887) listening? Message-ID: Got a BGP related issue that appears to be baffling your NOC because it doesn't involve fiber being down. From dmburgess at linktechs.net Fri Oct 19 03:55:45 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 18 Oct 2012 22:55:45 -0500 Subject: ATT Contact Needed Message-ID: <50710E9A7E64454C974049FC998EB655681FA3@03-exchange.lti.local> We have a ATT Fiber circuit in central US, nothing major, BGP issues with route damping on the juniper, my client has been down for over 5 hours (simply a route damping ) but no one can fix it, and all they can do is put a "ticket in" to the next tier .. Any help off list, or on-line as we are on the phone now trying to get them to do ANYTHING L ATT Ticket 160488513 Dennis Burgess, From randy at psg.com Fri Oct 19 07:03:47 2012 From: randy at psg.com (Randy Bush) Date: Thu, 18 Oct 2012 21:03:47 -1000 Subject: ATT Contact Needed In-Reply-To: <50710E9A7E64454C974049FC998EB655681FA3@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655681FA3@03-exchange.lti.local> Message-ID: > client has been down for over 5 hours (simply a route damping ) to aid possible at&t lurkers, what route, and where/why do you think it is damped? randy From mysidia at gmail.com Fri Oct 19 10:58:36 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 19 Oct 2012 05:58:36 -0500 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: On 10/17/12, Landon Stewart wrote: > it's difficult to decide what to do when it's already an issue. For > example in RFC 1034 section 3.6.2 the use of CNAME's with NS and MX records > is not permitted but other research shows this is widely used even though > its technically invalid. IMHO it should have never happened in the first A cached CNAME is used by a DNS resolver without querying for any other kind of RR. So, if there is a CNAME for a label, there cannot be any kind of RR other than a CNAME, they produce results for resolvers that depend upon which RRs are cached by the resolver. When a zone is delegated, there must be SOA and NS records in the child zone presented by the authoritative nameserver. You will need to perform DNS lookup operations, and examine the Additional Section of the response, in order to determine what the appropriate RRs should be to replace the CNAME. > # dig @ns1.superb.net +nocmd mail.customerzone.com A +noques +answer > ;; ANSWER SECTION: > mail.customerzone.com. 14342 IN CNAME mail.superb.net. > mail.customerzone.com. 86342 IN A xx.xx.246.9 In general, the CNAME will replace the name in this case, and the A record will be silently ignored; however, If mail.superb.net. in the authoritative superb.net. zone is not an A record containing xx.xx.246.9 for any reason, then the DNS resolver can have unpredictable results, that depend on the state of the cache at the time of the query. Unless "mail.superb.net." is a label in the superb.net. zone that contains one A record with an identical RDATA section, and You can guarantee that the A record in this zone, is always updated in this zone, whenever "mail.superb.net." happens to be changed or updated, and nobody ever ever changes mail.superb.net while neglecting to update the A record of mail.customerzone.com. Either the CNAME or the A record should be nuked in this case; you have a choice regarding which one to nuke, and it's important that you verify you have the result pointing to the right IP. > # dig @ns1.superb.net +nocmd superbcolo.biz NS +noques +answer > ;; ANSWER SECTION: > superbcolo.biz. 86400 IN NS ns1.superb.net. > superbcolo.biz. 86400 IN NS ns2.superb.net. > superbcolo.biz. 86400 IN NS ns3.superb.net. > superbcolo.biz. 86400 IN CNAME superbenterprise.net. CNAME'ing an entire zone is definitely not recommended; this impacts more than just an A type lookup for "superbcolo.biz.". You need a DNAME instead of CNAME to redirect subdomains of an entire DNS zone, and there may be limited support in DNS software. Technically, this would be valid, as long as superbenterprise.net is valid, has SOA and NS RRs, AND no subdomains or labels under superbcolo.biz. such as "www.superbcolo.biz." exist. If you have created SOAs and NS RRs for "superbcolo.biz." They are all to be looked up under superbenterprise.net. > # dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer > ;; ANSWER SECTION: > superbcolo.biz. 86400 IN MX 10 superbcolo.biz. > superbcolo.biz. 86400 IN CNAME superbenterprise.net. The general recommendation here, would be to DNS lookup superbcolo.biz, create the missing A and NS records, and remove the CNAME. > dig @ns1.superb.net +nocmd customerzone2.com SOA +noques +answer > ;; ANSWER SECTION: > customerzone2.com. 86400 IN CNAME superbenterprise.net. > customerzone2.com. 86400 IN SOA ns1.superb.net. hostmaster.superb.net. > 1350501302 0 0 0 0 > > Should the CNAME just get nuked in all of these cases? -- -JH From jerome at fleury.net Fri Oct 19 13:09:44 2012 From: jerome at fleury.net (=?ISO-8859-1?Q?J=E9r=F4me_Fleury?=) Date: Fri, 19 Oct 2012 15:09:44 +0200 Subject: Google opens Web Window on their Data Centers In-Reply-To: References: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> Message-ID: On Thu, Oct 18, 2012 at 5:34 PM, Tony Finch wrote: > Tony Patti wrote: >> >> http://www.google.com/about/datacenters/gallery/#/ > > Also worth seeing is this article which explains how their hot aisles work: > http://www.datacenterknowledge.com/archives/2012/10/17/how-google-cools-its-armada-of-servers/ > And this longer and fluffier piece in Wired: > http://www.wired.com/wiredenterprise/2012/10/ff-inside-google-data-center/all/ http://www.google.com/about/datacenters/gallery/#/tech/12 This picture has obviously been photoshopped. If you look closely, this is a mirrored picture: left and right sides are strictly the same. From baconzombie at gmail.com Fri Oct 19 13:38:48 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Fri, 19 Oct 2012 14:38:48 +0100 Subject: Google opens Web Window on their Data Centers In-Reply-To: References: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> Message-ID: It looks right the right-hand side is real and the left is just a mirror on most of the pictures. You can see from the LED's, empty slots in the racks, hanging cables and labels. Here is a collect of photos you from the Reddit thread on it: http://imgur.com/a/UBxVc Also they did not show any of their custom networking equipment. http://www.networking-forum.com/viewtopic.php?f=46&t=29803 The whole event was all just Smoke and Mirrors..... www.youtube.co.jp/watch?v=kU4RHfjeE8w On 19 October 2012 14:09, J?r?me Fleury wrote: > On Thu, Oct 18, 2012 at 5:34 PM, Tony Finch wrote: >> Tony Patti wrote: >>> >>> http://www.google.com/about/datacenters/gallery/#/ >> >> Also worth seeing is this article which explains how their hot aisles work: >> http://www.datacenterknowledge.com/archives/2012/10/17/how-google-cools-its-armada-of-servers/ >> And this longer and fluffier piece in Wired: >> http://www.wired.com/wiredenterprise/2012/10/ff-inside-google-data-center/all/ > > http://www.google.com/about/datacenters/gallery/#/tech/12 > > This picture has obviously been photoshopped. If you look closely, > this is a mirrored picture: left and right sides are strictly the > same. > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From tjc at ecs.soton.ac.uk Fri Oct 19 14:01:50 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 19 Oct 2012 15:01:50 +0100 Subject: Google opens Web Window on their Data Centers In-Reply-To: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> References: <1a2c01cdad3c$e2196310$a64c2930$@swalter.com> <810B5064-AAF8-4949-9DDA-7C2594A05563@ecs.soton.ac.uk> Message-ID: On 18 Oct 2012, at 15:28, Tony Patti wrote: > http://www.google.com/about/datacenters/gallery/#/ > > "Where the Internet lives - Take a look inside Google's high-tech data > centers" One of those photos looks like it came directly from the Hive in Resident Evil. Now we know... Tim From arturo.servin at gmail.com Fri Oct 19 17:56:23 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 19 Oct 2012 15:56:23 -0200 Subject: 169.254.0.0/16 In-Reply-To: References: <20121018151856.GD3768@puck.nether.net> Message-ID: <50819447.5070402@gmail.com> Wait! Are you suggesting to not use it as intended by RFC6598? "to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE)" :) .as On 18/10/2012 13:25, Christopher Morrow wrote: > On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas wrote: > >> RFCs are just paper. As for why they use it.. the common private >> use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use >> internally in their customers networks. This is probably the easiest >> way to avoid addressing conflicts. >> > > but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10 > > :) > From cscora at apnic.net Fri Oct 19 18:50:44 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Oct 2012 04:50:44 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201210191850.q9JIoivk021743@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 20 Oct, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 428559 Prefixes after maximum aggregation: 179230 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 210798 Total ASes present in the Internet Routing Table: 42395 Prefixes per ASN: 10.11 Origin-only ASes present in the Internet Routing Table: 33734 Origin ASes announcing only one prefix: 15789 Transit ASes present in the Internet Routing Table: 5646 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 853 Unregistered ASNs in the Routing Table: 317 Number of 32-bit ASNs allocated by the RIRs: 3396 Number of 32-bit ASNs visible in the Routing Table: 3015 Prefixes from 32-bit ASNs in the Routing Table: 8150 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 159 Number of addresses announced to Internet: 2606837356 Equivalent to 155 /8s, 97 /16s and 46 /24s Percentage of available address space announced: 70.4 Percentage of allocated address space announced: 70.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.8 Total number of prefixes smaller than registry allocations: 150124 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 103203 Total APNIC prefixes after maximum aggregation: 32571 APNIC Deaggregation factor: 3.17 Prefixes being announced from the APNIC address blocks: 103964 Unique aggregates announced from the APNIC address blocks: 43021 APNIC Region origin ASes present in the Internet Routing Table: 4773 APNIC Prefixes per ASN: 21.78 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 773 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 334 Number of APNIC addresses announced to Internet: 711007648 Equivalent to 42 /8s, 97 /16s and 29 /24s Percentage of available APNIC address space announced: 83.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, 131072-133119 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: 154687 Total ARIN prefixes after maximum aggregation: 78240 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155549 Unique aggregates announced from the ARIN address blocks: 69508 ARIN Region origin ASes present in the Internet Routing Table: 15279 ARIN Prefixes per ASN: 10.18 ARIN Region origin ASes announcing only one prefix: 5776 ARIN Region transit ASes present in the Internet Routing Table: 1594 Average ARIN Region AS path length visible: 4.2 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1086895232 Equivalent to 64 /8s, 200 /16s and 180 /24s Percentage of available ARIN address space announced: 57.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 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: 108941 Total RIPE prefixes after maximum aggregation: 57423 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 111567 Unique aggregates announced from the RIPE address blocks: 71809 RIPE Region origin ASes present in the Internet Routing Table: 16909 RIPE Prefixes per ASN: 6.60 RIPE Region origin ASes announcing only one prefix: 8137 RIPE Region transit ASes present in the Internet Routing Table: 2742 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1960 Number of RIPE addresses announced to Internet: 648350500 Equivalent to 38 /8s, 165 /16s and 11 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 43966 Total LACNIC prefixes after maximum aggregation: 8703 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 47340 Unique aggregates announced from the LACNIC address blocks: 22764 LACNIC Region origin ASes present in the Internet Routing Table: 1679 LACNIC Prefixes per ASN: 28.20 LACNIC Region origin ASes announcing only one prefix: 460 LACNIC Region transit ASes present in the Internet Routing Table: 320 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 698 Number of LACNIC addresses announced to Internet: 117995816 Equivalent to 7 /8s, 8 /16s and 121 /24s Percentage of available LACNIC address space announced: 70.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9492 Total AfriNIC prefixes after maximum aggregation: 2239 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 9980 Unique aggregates announced from the AfriNIC address blocks: 3557 AfriNIC Region origin ASes present in the Internet Routing Table: 566 AfriNIC Prefixes per ASN: 17.63 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 42290432 Equivalent to 2 /8s, 133 /16s and 77 /24s Percentage of available AfriNIC address space announced: 42.0 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 2968 11430 899 Korea Telecom (KIX) 17974 2366 830 54 PT TELEKOMUNIKASI INDONESIA 7545 1775 301 87 TPG Internet Pty Ltd 4755 1617 387 163 TATA Communications formerly 9829 1409 1154 41 BSNL National Internet Backbo 9583 1199 89 512 Sify Limited 4808 1112 2056 315 CNCGROUP IP network: China169 7552 1090 1062 15 Vietel Corporation 24560 1036 385 162 Bharti Airtel Ltd., Telemedia 9498 1019 307 69 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 3187 3726 166 bellsouth.net, inc. 7029 3136 990 162 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1926 678 126 PaeTec Communications, Inc. 22773 1907 2931 128 Cox Communications, Inc. 20115 1660 1583 615 Charter Communications 4323 1590 1155 392 Time Warner Telecom 30036 1353 269 748 Mediacom Communications Corp 7018 1270 10303 843 AT&T WorldNet Services 7011 1220 333 690 Citizens Utilities 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 8402 1783 544 16 Corbina telecom 2118 1172 97 14 EUnet/RELCOM Autonomous Syste 12479 851 776 64 Uni2 Autonomous System 34984 813 207 189 BILISIM TELEKOM 31148 725 37 9 FreeNet ISP 6830 723 2313 445 UPC Distribution Services 20940 706 223 548 Akamai Technologies European 13188 702 93 144 Educational Network 58113 602 67 364 LIR DATACENTER TELECOM SRL 8551 575 364 61 Bezeq International 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 2194 378 227 TVCABLE BOGOTA 28573 2139 1277 60 NET Servicos de Comunicao S.A 7303 1662 1131 203 Telecom Argentina Stet-France 8151 1590 3028 355 UniNet S.A. de C.V. 6503 1539 435 69 AVANTEL, S.A. 27947 737 74 95 Telconet S.A 3816 649 309 70 Empresa Nacional de Telecomun 11172 596 85 66 Servicios Alestra S.A de C.V 14420 589 87 102 CORPORACION NACIONAL DE TELEC 7738 586 1178 33 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 895 275 36 LINKdotNET AS number 36998 672 48 3 MOBITEL 8452 644 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 270 80 8 RAYA Telecom - Egypt 3741 266 906 224 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 192 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 172 682 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3187 3726 166 bellsouth.net, inc. 7029 3136 990 162 Windstream Communications Inc 4766 2968 11430 899 Korea Telecom (KIX) 17974 2366 830 54 PT TELEKOMUNIKASI INDONESIA 10620 2194 378 227 TVCABLE BOGOTA 28573 2139 1277 60 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1926 678 126 PaeTec Communications, Inc. 22773 1907 2931 128 Cox Communications, Inc. 8402 1783 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3136 2974 Windstream Communications Inc 17974 2366 2312 PT TELEKOMUNIKASI INDONESIA 28573 2139 2079 NET Servicos de Comunicao S.A 4766 2968 2069 Korea Telecom (KIX) 10620 2194 1967 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 1785 1926 1800 PaeTec Communications, Inc. 22773 1907 1779 Cox Communications, Inc. 8402 1783 1767 Corbina telecom 7545 1775 1688 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 41.220.81.0/24 38925 DAC AS Germany 41.220.94.0/23 42235 Intra Data Communication 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 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:18 /9:14 /10:29 /11:87 /12:242 /13:478 /14:849 /15:1547 /16:12450 /17:6502 /18:10844 /19:21201 /20:30464 /21:32460 /22:42916 /23:40154 /24:224076 /25:1352 /26:1684 /27:907 /28:177 /29:66 /30:17 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2625 3136 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1792 3187 bellsouth.net, inc. 8402 1493 1783 Corbina telecom 30036 1280 1353 Mediacom Communications Corp 22773 1247 1907 Cox Communications, Inc. 11492 1148 1183 Cable One 6503 1054 1539 AVANTEL, S.A. 1785 1016 1926 PaeTec Communications, Inc. 7011 956 1220 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:648 2:771 3:1 4:13 5:576 6:3 8:474 12:1982 13:1 14:669 15:11 16:3 17:6 20:27 23:211 24:1789 27:1369 31:1031 32:54 33:2 34:2 36:7 37:860 38:830 39:2 40:136 41:2757 42:158 44:3 46:1650 47:2 49:455 50:598 52:12 54:25 55:8 56:5 57:27 58:983 59:546 60:236 61:1294 62:940 63:2001 64:4281 65:2231 66:4529 67:2077 68:1153 69:3231 70:987 71:505 72:1868 74:2609 75:481 76:309 77:984 78:981 79:503 80:1233 81:970 82:623 83:542 84:521 85:1153 86:484 87:943 88:360 89:1804 90:304 91:5257 92:584 93:1465 94:1644 95:1143 96:396 97:325 98:973 99:39 100:32 101:269 103:1663 105:428 106:121 107:201 108:484 109:1586 110:805 111:972 112:435 113:727 114:629 115:891 116:895 117:755 118:945 119:1223 120:332 121:689 122:1698 123:1163 124:1340 125:1282 128:569 129:196 130:284 131:611 132:304 133:22 134:250 135:62 136:219 137:241 138:338 139:170 140:492 141:286 142:492 143:380 144:498 145:82 146:507 147:268 148:756 149:331 150:154 151:199 152:448 153:179 154:20 155:431 156:227 157:373 158:258 159:660 160:339 161:412 162:365 163:191 164:706 165:442 166:526 167:555 168:993 169:126 170:920 171:166 172:7 173:1657 174:616 175:453 176:766 177:1285 178:1611 180:1347 181:162 182:1106 183:314 184:608 185:28 186:2218 187:1334 188:1692 189:1599 190:5822 192:6050 193:5535 194:4595 195:3663 196:1230 197:244 198:3864 199:5098 200:5982 201:1969 202:8683 203:8719 204:4413 205:2530 206:2771 207:2804 208:4070 209:3627 210:2834 211:1535 212:2009 213:1851 214:897 215:87 216:5121 217:1570 218:572 219:314 220:1252 221:532 222:337 223:410 End of report From joelja at bogus.com Fri Oct 19 19:45:42 2012 From: joelja at bogus.com (joel jaeggli) Date: Fri, 19 Oct 2012 12:45:42 -0700 Subject: 169.254.0.0/16 In-Reply-To: <50819447.5070402@gmail.com> References: <20121018151856.GD3768@puck.nether.net> <50819447.5070402@gmail.com> Message-ID: <5081ADE6.7030006@bogus.com> On 10/19/12 10:56 AM, Arturo Servin wrote: > Wait! > > Are you suggesting to not use it as intended by RFC6598? > > "to > be used as Shared Address Space to accommodate the needs of Carrier- > Grade NAT (CGN) devices. It is anticipated that Service Providers > will use this Shared Address Space to number the interfaces that > connect CGN devices to Customer Premises Equipment (CPE)" > > > :) It's a private scope address range what you actually do with it only Germain within your span of control. unless you 're sufficiently unwise as to be accepting leaked routes from you upstream in which case it isn't. http://bgp.he.net/net/100.100.0.0/24#_bogon > .as > > > > On 18/10/2012 13:25, Christopher Morrow wrote: >> On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas wrote: >> >>> RFCs are just paper. As for why they use it.. the common private >>> use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use >>> internally in their customers networks. This is probably the easiest >>> way to avoid addressing conflicts. >>> >> but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10 >> >> :) >> From jmaslak at antelope.net Fri Oct 19 20:13:26 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 19 Oct 2012 14:13:26 -0600 Subject: Centurylink Contact Message-ID: Does anyone have a good contact to report outside plant issues in the Denver, CO area? Some construction equipment in my neighborhood snagged and snapped a messenger cable between poles, and probably stretched some copper. I'd like to make sure that CL actually gets notified and gets it fixed. My line is fine, so their automated residential customer service line wasn't helping me at all. From quantumfoam at gmail.com Fri Oct 19 20:16:43 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Fri, 19 Oct 2012 16:16:43 -0400 Subject: Centurylink Contact In-Reply-To: References: Message-ID: I'd say call the control center at 1.800.524.5249. And then wait. And wait. And wait. You're gonna need a Snickers. --JR On Fri, Oct 19, 2012 at 4:13 PM, Joel Maslak wrote: > Does anyone have a good contact to report outside plant issues in the > Denver, CO area? > > Some construction equipment in my neighborhood snagged and snapped a > messenger cable between poles, and probably stretched some copper. > I'd like to make sure that CL actually gets notified and gets it > fixed. My line is fine, so their automated residential customer > service line wasn't helping me at all. > > From kbroder at accretive-networks.net Fri Oct 19 20:17:58 2012 From: kbroder at accretive-networks.net (Kevin Broderick) Date: Fri, 19 Oct 2012 13:17:58 -0700 Subject: Centurylink Contact In-Reply-To: References: Message-ID: If it was the cut that happened at 10:40 PDT it was restored at 12:50 PDT. We lost RX on a circuit, but not TX. Kevin Broderick - IT Operations Manager --------------------------------------- IT Operations/Network Engineering Accretive Networks / Wolfe.Net / CamTV ITOps at accretivetg.com p 206.269.0190 t 800.965.3363 f 206.269.0188 -----Original Message----- From: Joel Maslak [mailto:jmaslak at antelope.net] Sent: Friday, October 19, 2012 1:13 PM To: NANOG list Subject: Centurylink Contact Does anyone have a good contact to report outside plant issues in the Denver, CO area? Some construction equipment in my neighborhood snagged and snapped a messenger cable between poles, and probably stretched some copper. I'd like to make sure that CL actually gets notified and gets it fixed. My line is fine, so their automated residential customer service line wasn't helping me at all. From deric.kwok2000 at gmail.com Fri Oct 19 20:40:05 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Fri, 19 Oct 2012 16:40:05 -0400 Subject: fibre question and any experience about BTI7000 Series Message-ID: Hi all Can you share your experience about DW DM? which applicance is better? Price reasonable and reliable Any experience about BTI 7000 Series Thank you so much From morrowc.lists at gmail.com Fri Oct 19 20:57:51 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Oct 2012 16:57:51 -0400 Subject: fibre question and any experience about BTI7000 Series In-Reply-To: References: Message-ID: there's a large set of questions you missed, perhaps you'd like to start with: specifically the presentation that goes with: there's even video: On Fri, Oct 19, 2012 at 4:40 PM, Deric Kwok wrote: > Hi all > > Can you share your experience about DW DM? which applicance is better? > > Price reasonable and reliable > > Any experience about BTI 7000 Series > > Thank you so much > From cidr-report at potaroo.net Fri Oct 19 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Oct 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201210192200.q9JM00Uu088546@wattle.apnic.net> This report has been generated at Fri Oct 19 21:13:05 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-10-12 430924 249107 13-10-12 431004 249285 14-10-12 431108 249232 15-10-12 431195 249093 16-10-12 430863 249006 17-10-12 430696 249377 18-10-12 431071 249424 19-10-12 430920 249860 AS Summary 42504 Number of ASes in routing system 17685 Number of ASes announcing only one prefix 3186 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113900768 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 19Oct12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 431409 249790 181619 42.1% All ASes AS6389 3186 171 3015 94.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2142 61 2081 97.2% NET Servicos de Comunicao S.A. AS4766 2973 939 2034 68.4% KIXS-AS-KR Korea Telecom AS17974 2366 567 1799 76.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3135 1460 1675 53.4% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1907 338 1569 82.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2194 823 1371 62.5% Telmex Colombia S.A. AS7303 1662 427 1235 74.3% Telecom Argentina S.A. AS4323 1594 398 1196 75.0% TWTC - tw telecom holdings, inc. AS2118 1172 87 1085 92.6% RELCOM-AS OOO "NPO Relcom" AS4755 1617 537 1080 66.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1091 158 933 85.5% VIETEL-AS-AP Vietel Corporation AS1785 1926 1031 895 46.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1597 718 879 55.0% Uninet S.A. de C.V. AS18101 1018 175 843 82.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1112 348 764 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 863 116 747 86.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 695 52 643 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1112 483 629 56.6% LEVEL3 Level 3 Communications AS7545 1776 1152 624 35.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS17676 710 88 622 87.6% GIGAINFRA Softbank BB Corp. AS22561 1038 431 607 58.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS24560 1035 442 593 57.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1031 439 592 57.4% GBLX Global Crossing Ltd. AS19262 1001 409 592 59.1% VZGNI-TRANSIT - Verizon Online LLC AS4804 671 97 574 85.5% MPX-AS Microplex PTY LTD AS4780 840 272 568 67.6% SEEDNET Digital United Inc. AS22047 580 34 546 94.1% VTR BANDA ANCHA S.A. AS18881 577 45 532 92.2% Global Village Telecom Total 44705 12721 31984 71.5% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 65.111.16.0/20 AS26407 GUILFORD-COMMUNICATIONS - Guilford Communications, Inc. 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.39.128.0/19 AS11069 EGIX-INDY-AS-11069 - Egix, Inc. 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.7.60.0/22 AS39783 RENTARACK-AS Rent a Rack AS 192.0.0.0/24 AS11855 ASN-INTERNAP-BLK - Internap Network Services Corporation 198.18.0.0/15 AS11855 ASN-INTERNAP-BLK - Internap Network Services Corporation 198.51.100.0/24 AS11855 ASN-INTERNAP-BLK - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS52390 Administradora de Redes, S.A. 200.75.185.0/24 AS52390 Administradora de Redes, S.A. 200.75.186.0/23 AS52390 Administradora de Redes, S.A. 200.75.188.0/22 AS52390 Administradora de Redes, S.A. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS11855 ASN-INTERNAP-BLK - Internap Network Services Corporation 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 19 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Oct 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201210192200.q9JM02BK088567@wattle.apnic.net> BGP Update Report Interval: 11-Oct-12 -to- 18-Oct-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31560 708954 15.8% 10425.8 -- INSOURCE Insource LLC 2 - AS52107 329140 7.3% 10285.6 -- CPOINT-AS LLC "C Point" 3 - AS29076 263588 5.9% 9413.9 -- CITYTELECOM-AS Citytelecom.ru 4 - AS44436 189479 4.2% 6533.8 -- EFFORTEL-AS LLC MyBox 5 - AS5800 132565 3.0% 515.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS48366 63931 1.4% 7103.4 -- INFOROOM Inforoom Ltd. 7 - AS6903 62763 1.4% 10460.5 -- ZENON-AS ZENON N.S.P. 8 - AS27065 45305 1.0% 448.6 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 9 - AS41225 41832 0.9% 10458.0 -- MASTERLINK-AS ISP MasterLink 10 - AS10620 39318 0.9% 21.2 -- Telmex Colombia S.A. 11 - AS8402 36621 0.8% 35.5 -- CORBINA-AS OJSC "Vimpelcom" 12 - AS1637 31823 0.7% 357.6 -- DNIC-AS-01637 - Headquarters, USAISC 13 - AS26827 31086 0.7% 1942.9 -- EPBTELECOM - EPB Telecom 14 - AS1502 31085 0.7% 425.8 -- DNIC-ASBLK-01500-01502 - Headquarters, USAISC 15 - AS28306 29124 0.7% 4854.0 -- TC Net Inform?tica e Telecomunica??es LTDA 16 - AS2118 28701 0.6% 20.5 -- RELCOM-AS OOO "NPO Relcom" 17 - AS9829 28060 0.6% 29.0 -- BSNL-NIB National Internet Backbone 18 - AS22561 23288 0.5% 287.5 -- DIGITAL-TELEPORT - Digital Teleport Inc. 19 - AS28761 22577 0.5% 2822.1 -- SCIENTIFIC-INDUSTRIAL_ENTERPRISE_MYST Scientific-Industrial Enterprise "Myst" LLC 20 - AS6035 22094 0.5% 394.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS43307 10734 0.2% 10734.0 -- ALTLINUX-AS ALT Linux Technology 2 - AS50548 10710 0.2% 10710.0 -- QWENET-AS Qwe.Net ISP 3 - AS29503 10709 0.2% 10709.0 -- RATMIR-MOSCOW-AS Ratmir KDS 4 - AS49124 21416 0.5% 10708.0 -- CENTROSET-AS CentroSet Ltd. 5 - AS12608 21412 0.5% 10706.0 -- MAXHOSTING-AS MediaServicePlus Ltd. 6 - AS57191 10695 0.2% 10695.0 -- CHUDOTELECOM-AS IT Business Ltd. 7 - AS3 10664 0.2% 1618.0 -- CMED-AS Cmed Technology Ltd 8 - AS47747 10603 0.2% 10603.0 -- TMK-NET-AS JSC "TMK-Telekom" 9 - AS42974 10589 0.2% 10589.0 -- NET-SBERBANK-AST CJSC Sberbank-AST 10 - AS51699 10547 0.2% 10547.0 -- ANTARKTIDA-PLUS-AS Antarktida-Plus LLC 11 - AS44849 21000 0.5% 10500.0 -- SDN-SETI-AS S.D.N. Seti Ltd. 12 - AS58133 10489 0.2% 10489.0 -- ITS-LTD-AS Information Technology Systems Ltd 13 - AS58049 10469 0.2% 10469.0 -- TECHSUPPORT-AS Telecom Tekhpodderzhka Ltd 14 - AS47577 10465 0.2% 10465.0 -- IXBT-AS Righthosting Ltd 15 - AS44679 10464 0.2% 10464.0 -- LEXGROUP-AS Lex Group AS 16 - AS6903 62763 1.4% 10460.5 -- ZENON-AS ZENON N.S.P. 17 - AS41225 41832 0.9% 10458.0 -- MASTERLINK-AS ISP MasterLink 18 - AS31240 20889 0.5% 10444.5 -- OLD-HT-SYSTEMS-AS JSC Hosting Telesystems autonomous system 19 - AS49184 10440 0.2% 10440.0 -- STV-AS Group of companies STV Ltd 20 - AS31560 708954 15.8% 10425.8 -- INSOURCE Insource LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 16956 0.4% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 12748 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 217.12.32.0/21 10872 0.2% AS48383 -- DELTA-AS Delta LLC 4 - 213.148.16.0/22 10738 0.2% AS28738 -- INTERLAN-AS LLC Company Interlan Communications 5 - 194.107.17.0/24 10734 0.2% AS43307 -- ALTLINUX-AS ALT Linux Technology 6 - 193.222.52.0/22 10730 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 7 - 217.65.0.0/20 10724 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 8 - 195.60.227.0/24 10720 0.2% AS39528 -- SANCITY Sancity Project 9 - 195.88.126.0/23 10719 0.2% AS49124 -- CENTROSET-AS CentroSet Ltd. 10 - 195.128.48.0/21 10715 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 11 - 193.109.247.0/24 10711 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 12 - 193.107.40.0/22 10710 0.2% AS50548 -- QWENET-AS Qwe.Net ISP 13 - 217.146.32.0/22 10709 0.2% AS29503 -- RATMIR-MOSCOW-AS Ratmir KDS 14 - 192.162.100.0/22 10707 0.2% AS12608 -- MAXHOSTING-AS MediaServicePlus Ltd. 15 - 193.0.200.0/22 10705 0.2% AS12608 -- MAXHOSTING-AS MediaServicePlus Ltd. 16 - 192.105.75.0/24 10698 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 17 - 176.112.88.0/21 10697 0.2% AS49124 -- CENTROSET-AS CentroSet Ltd. 18 - 146.120.95.0/24 10695 0.2% AS57191 -- CHUDOTELECOM-AS IT Business Ltd. 19 - 193.105.100.0/24 10694 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.ru 20 - 193.104.76.0/24 10693 0.2% AS29076 -- CITYTELECOM-AS Citytelecom.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 mohta at necom830.hpcl.titech.ac.jp Fri Oct 19 22:05:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 20 Oct 2012 07:05:35 +0900 Subject: DNS hostnames with a duplicate CNAME and A record - which should be removed? In-Reply-To: References: Message-ID: <5081CEAF.7050503@necom830.hpcl.titech.ac.jp> Landon Stewart wrote: > I've been reading various sites and information including RFC 1034 but > it's difficult to decide what to do when it's already an issue. For > example in RFC 1034 section 3.6.2 the use of CNAME's with NS and MX records > is not permitted but other research shows this is widely used even though > its technically invalid. IMHO it should have never happened in the first > place (where an A record already exists a CNAME should not have been > allowed to get added for example) but what can be done now that it's > already an issue? The rule of RFC1034 is not applicable to secure DNS. W.r.t. RFC1034, the following text: The one exception to this rule is that queries which match the CNAME type are not restarted. is the key. For name servers, any RR types which may coexist with CNAME must also match CNAME. In addition, for queries with such RR types, cached CNAME without cached exact RR types should be ignored. > In the case of the A,NS,MX,SOA and CNAME duplicates an example of how our > old/current name server's responses are: > (*note: not all of this is real data, customer zones have been obfuscated)* SOA and NS could have matched CNAME, which enables a zone containing just a CNAME, though RFC1034 does not specify so. It is not harmful except that queries with SOA or NS type may cause loops if some cache have CNAME RRs. Masataka Ohta From joelja at bogus.com Sat Oct 20 19:22:38 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 20 Oct 2012 12:22:38 -0700 Subject: 169.254.0.0/16 In-Reply-To: References: Message-ID: <5082F9FE.6000604@bogus.com> On 10/17/12 10:59 AM, Darren O'Connor wrote: > I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space. > > RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address. > > So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it? Given the frequency with which adhoc networks are numbered out of this prefix, it's existence is far from wasted. The term waste is exercised far to liberally in the context of address mangement as far as I'm concerned. If you are unconcerned with possible collisions with ephemeral uses of this space then I imagine you could reuse it for some internal purpose. It is probably important to be aware that unmanaged end systems will use it in an uncoordinated fashion (and make assumptions about the scope of addresses in that range) and that it would therefore be a good idea to limit applications to those which cannot be impacted by that behavior. Amazon does number our VPC peer links out of there. coordinating the existance of multiple private clouds all numbered out of potentially overlapping rfc-1918 address space is probably the motivation for doing so. > Thanks > > Darren > > From randy at psg.com Sat Oct 20 22:41:01 2012 From: randy at psg.com (Randy Bush) Date: Sat, 20 Oct 2012 12:41:01 -1000 Subject: abha ahuja Message-ID: abha ahuja died this day in 2001. wonderful person, good netizen, good researcher. sigh. From patrick at newnog.org Sat Oct 20 23:33:02 2012 From: patrick at newnog.org (Patrick W. Gilmore) Date: Sat, 20 Oct 2012 18:33:02 -0500 Subject: [NANOG-announce] Elections open tomorrow Message-ID: Everyone: NANOG elections open tomorrow. Please consider standing for one of the committees, or nominating someone for the committees. Remember, committee members get free registration to every NANOG meeting! The only requirement is a willingness to contribute to the community, and being a NANOG member. To nominate someone, send their name and email address to elections at nanog.org. Elections will close Tuesday at 1700 CDT (UTC-0500). And thank you for being part of the NANOG community! -- TTFN, patrick _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From bootc at bootc.net Thu Oct 18 16:31:05 2012 From: bootc at bootc.net (Chris Boot) Date: Thu, 18 Oct 2012 17:31:05 +0100 Subject: Detection of Rogue Access Points In-Reply-To: References: <508000E6.8060003@jasonantman.com> Message-ID: <50802EC9.8020002@bootc.net> On 18/10/12 15:12, Joe Hamelin wrote: > On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers > wrote: > >> I like the idea of looking at the ARP table periodically, but this presents >> some possible issues for us. > > Is it just WAPs that you are worried about or any rouge device at the > remote sites? If you're doing medical data then I would think that any > non-company device would be suspect. If that is the case then ARP scraping > is the better way. Basically you need an inventory of what is at the > sites. This you should already have and if you don't, that is your first > step. > > A bit of perl and expect scripting would get you a long way to your goal. > Like I mentioned before, if you don't have the time/talent to script the > task, call out for a coder-for-hire. You should be able to get the ARP table off a router using SNMP, which would be much cleaner than using expect to login to a router's management interface... HTH, Chris From fred at cisco.com Sun Oct 21 09:36:29 2012 From: fred at cisco.com (Fred Baker (fred)) Date: Sun, 21 Oct 2012 09:36:29 +0000 Subject: abha ahuja In-Reply-To: References: Message-ID: <8C48B86A895913448548E6D15DA7553B180BCE@xmb-rcd-x09.cisco.com> On Oct 20, 2012, at 3:41 PM, Randy Bush wrote: > abha ahuja died this day in 2001. wonderful person, good netizen, good > researcher. sigh. Yes. She is missed. From leen at consolejunkie.net Sun Oct 21 10:37:30 2012 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 21 Oct 2012 12:37:30 +0200 Subject: Please, talk me down. In-Reply-To: References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> Message-ID: <20121021103730.GA19451@apia.perrit.net> On Wed, Oct 17, 2012 at 09:45:09PM -0500, Jimmy Hess wrote: > On 10/16/12, Randy Bush wrote: > >> First off, I'm using djbdns internally and it doesn't support AAAA > >> records. So we really aren't using it internally. > > if the clutch in my car is broken, should i stop using vehicles? > > dump djbdns or get some diehard to tell you how to fix it. > > Ah, but the clutch is not actually broken; it works perfectly, and > it is a very robust clutch, not likely to break, it's just that the > car was designed, so you need a wrench with you while at all times > while driving, to actuate the clutch, and you need a screwdriver > onhand as well to adjust gears. They have a raw record format, > that allows you to enter a raw record into your tinydns data file, > containing anything, including AAAA data. > > However, djbdns also lacks support for DNSSEC validation. the stock > package 1.05, when installed on a 64-bit OS, contained an unpatched > security vulnerability. > If Joseph really likes to use the TinyDNS database so much there is an experimental PowerDNS backend of supposedly there is even an even more DNSSEC-patch somewhere. I can't find the patch right now, but it was mentioned in a presentation by the head developer at ICANN44: http://prague44.icann.org/node/31749 Here it the audio recording: http://audio.icann.org/meetings/prague2012/dnssec-workshop-27jun12-en.mp3 (135 MB) His presentation starts at: 3:32:18 He mentions it at: 3:46:53 And the PDF of his presentation is here: http://prague44.icann.org/meetings/prague2012/presentation-dnssec-power-dns-27jun12-en.pdf I don't expect anyone is using patch in production right now. > The car was also designed with no electric ignition switch, and no > headlights. You want to start your car, you need a manual crank. > It's "good enough"; but probably the time comes soon to retire it. > > Electronic ignitions and headlights became the 'standard' a long time > ago, but the car design was never improved to include the features > (not necessarily an easy feat) -- meanwhile, the person in > charge of maintaining the design; spent many hours writing essays > about the problem of light pollution caused by headlights, > insisting that road lights instead would be better, and calling up > issues about the extra weight and space required for batteries, > danger of batteries leaking, or failing, leaving motorists > stranded, etc, > thus spending time not updating the design to incorporate beneficial, > new standards. > > > > randy > -- > -JH > Have a nice day, Leen. From jay at miscreant.org Sun Oct 21 10:59:40 2012 From: jay at miscreant.org (Jay Mitchell) Date: Sun, 21 Oct 2012 21:59:40 +1100 Subject: Please, talk me down. In-Reply-To: <20121017204423.GA30547@vectra.student.iastate.edu> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> <20121017204423.GA30547@vectra.student.iastate.edu> Message-ID: <8E129D79-1C82-42DB-BD15-5C873AEE3C66@miscreant.org> On 18/10/2012, at 7:44 AM, Nicolai wrote: > On Wed, Oct 17, 2012 at 03:35:11AM +0000, Joseph Anthony Pasquale Holsten wrote: > >> First off, I'm using djbdns internally and it doesn't support AAAA >> records. So we really aren't using it internally. > > I assume you mean stock djbdns doesn't support ip6, because it doesindeed support AAAA records. I use both dnscache and tinydns from > djbdns and AAAA records work fine for me. Note: I'm not using Felix von > Leitner's ip6 patch. > > $ dig aaaa chocolatine.org +short > 2610:130:103:e00:201:2ff:fe45:8308 > > Resolver is dnscache, authoritate server is tinydns. No problem. > > I think the problem you're experiencing, if there is one, is not related > to either djbdns or ip6. > > Nicolai > From jay at miscreant.org Sun Oct 21 11:09:24 2012 From: jay at miscreant.org (Jay Mitchell) Date: Sun, 21 Oct 2012 22:09:24 +1100 Subject: Please, talk me down. In-Reply-To: <20121017204423.GA30547@vectra.student.iastate.edu> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> <20121017204423.GA30547@vectra.student.iastate.edu> Message-ID: <58C92948-0900-4CCB-99FF-F110F90C2FCA@miscreant.org> Apologies for the empty reply, mobile typo machine at work :( On 18/10/2012, at 7:44 AM, Nicolai wrote: > On Wed, Oct 17, 2012 at 03:35:11AM +0000, Joseph Anthony Pasquale Holsten wrote: > >> First off, I'm using djbdns internally and it doesn't support AAAA >> records. So we really aren't using it internally. > > I assume you mean stock djbdns doesn't support ip6, because it does > indeed support AAAA records. Actually, it doesn't, as you so kindly pointed out. It does WITH a patch. > I use both dnscache and tinydns from > djbdns and AAAA records work fine for me. Note: I'm not using Felix von > Leitner's ip6 patch. > Thanks for pointing that out, finally. > $ dig aaaa chocolatine.org +short > 2610:130:103:e00:201:2ff:fe45:8308 > > Resolver is dnscache, authoritate server is tinydns. No problem. > > I think the problem you're experiencing, if there is one, is not related > to either djbdns or ip6. > For real? Go figure. > Nicolai > From ema at merit.edu Sun Oct 21 15:55:59 2012 From: ema at merit.edu (Eric Aupperle) Date: Sun, 21 Oct 2012 11:55:59 -0400 Subject: abha ahuja In-Reply-To: References: Message-ID: <2893AB3B-653F-4E27-A855-777F54E887FC@merit.edu> Very sad indeed. She contributed much to the net and Merit. On Oct 20, 2012, at 6:41 PM, Randy Bush wrote: > abha ahuja died this day in 2001. wonderful person, good netizen, good > researcher. sigh. > From nicolai-nanog at chocolatine.org Sun Oct 21 21:06:58 2012 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Sun, 21 Oct 2012 16:06:58 -0500 Subject: Please, talk me down. In-Reply-To: <58C92948-0900-4CCB-99FF-F110F90C2FCA@miscreant.org> References: <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> <20121017204423.GA30547@vectra.student.iastate.edu> <58C92948-0900-4CCB-99FF-F110F90C2FCA@miscreant.org> Message-ID: <20121021210658.GA11698@vectra.student.iastate.edu> On Sun, Oct 21, 2012 at 10:09:24PM +1100, Jay Mitchell wrote: > On 18/10/2012, at 7:44 AM, Nicolai wrote: > > I assume you mean stock djbdns doesn't support ip6, because it does > > indeed support AAAA records. > > Actually, it doesn't, as you so kindly pointed out. It does WITH a patch. No. djbdns 1.05 supports AAAA records as anyone can verify. To make sure myself I just downloaded stock djbdns from the cr.yp.to website, installed, and ran some aaaa queries. Works as it always has. $ dig aaaa he.net +short 2001:470:0:76::2 That's an unpatched, stock dnscache. John Levine already described in this thread how tinydns supports AAAA records, so there's no point going over it again. I only responded to this thread to correct misinformation. sigh As an aside, you may want to fix your DNS, as some mail receivers don't like this: $ dig -x 72.249.91.101 +short static.serversandhosting.com. $ dig a static.serversandhosting.com +short 72.249.3.27 Nicolai From kmedcalf at dessus.com Mon Oct 22 03:49:54 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 21 Oct 2012 21:49:54 -0600 Subject: Please, talk me down. In-Reply-To: <20121021210658.GA11698@vectra.student.iastate.edu> Message-ID: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> > As an aside, you may want to fix your DNS, as some mail receivers don't > like this: > $ dig -x 72.249.91.101 +short > static.serversandhosting.com. > $ dig a static.serversandhosting.com +short > 72.249.3.27 What is really meant to be said is that MTA's which require RFC compliance won't talk to you. Running an MTA which requires minimal RFC compliance (particularly in respect of DNS configuration) eliminates 98% of spam. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From ops.lists at gmail.com Mon Oct 22 03:56:18 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 22 Oct 2012 09:26:18 +0530 Subject: Please, talk me down. In-Reply-To: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> References: <20121021210658.GA11698@vectra.student.iastate.edu> <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> Message-ID: On Mon, Oct 22, 2012 at 9:19 AM, Keith Medcalf wrote: > > What is really meant to be said is that MTA's which require RFC compliance won't talk to you. Running an MTA which requires minimal RFC compliance (particularly in respect of DNS configuration) eliminates 98% of spam. I wish it were that easy. -- Suresh Ramasubramanian (ops.lists at gmail.com) From marka at isc.org Mon Oct 22 04:18:52 2012 From: marka at isc.org (Mark Andrews) Date: Mon, 22 Oct 2012 15:18:52 +1100 Subject: Please, talk me down. In-Reply-To: Your message of "Sun, 21 Oct 2012 21:49:54 MDT." <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> Message-ID: <20121022041852.401AC2A18950@drugs.dv.isc.org> In message <83452cbbe5c3c5439212c8a56346b283 at mail.dessus.com>, "Keith Medcalf" writes: > > As an aside, you may want to fix your DNS, as some mail receivers don't > > like this: > > > $ dig -x 72.249.91.101 +short > > static.serversandhosting.com. > > $ dig a static.serversandhosting.com +short > > 72.249.3.27 > > What is really meant to be said is that MTA's which require RFC compliance = > won't talk to you. Running an MTA which requires minimal RFC compliance (p= > articularly in respect of DNS configuration) eliminates 98% of spam. Standards track RFC compliance REQUIRES that you ACCEPT email from that box. There is no standards track RFC that requires that PTR records exist. There is no standards track RFC that requires that PTR and address records are consistent. It is however good practice that these exist and are consistent. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Sean.Pedersen at usairways.com Mon Oct 22 15:06:29 2012 From: Sean.Pedersen at usairways.com (Pedersen, Sean) Date: Mon, 22 Oct 2012 08:06:29 -0700 Subject: Semi-automated L3 interface DNS records In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431FD9@PHX-52N-EXM04A.lcc.usairways.com> Thanks to everyone that responded. Based on the information from this list and several other areas I posted the same question, it seems like a feasible goal. If anyone has any ideas on how to either reduce my sleeping requirements or extend the number of hours in a day so that I can actually implement this, I would love to hear from you. :-P -----Original Message----- From: Pedersen, Sean [mailto:Sean.Pedersen at usairways.com] Sent: Thursday, October 18, 2012 12:57 PM To: nanog at nanog.org Subject: Semi-automated L3 interface DNS records Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. From asullivan at dyn.com Mon Oct 22 16:36:53 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Mon, 22 Oct 2012 12:36:53 -0400 Subject: forward and reverse DNS (was: Please, talk me down.) In-Reply-To: <20121022041852.401AC2A18950@drugs.dv.isc.org> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> Message-ID: <20121022163626.GA50527@dyn.com> On Mon, Oct 22, 2012 at 03:18:52PM +1100, Mark Andrews wrote: > records are consistent. It is however good practice that these exist and > are consistent. I will note that the IETF DNSOP WG was unable to agree even on that latter claim. A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From paul.zugnoni at jivesoftware.com Mon Oct 22 22:07:50 2012 From: paul.zugnoni at jivesoftware.com (Paul Zugnoni) Date: Mon, 22 Oct 2012 22:07:50 +0000 Subject: Issues encountered with assigning .0 and .255 as usable addresses? Message-ID: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy?. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. From contact at nullivex.com Mon Oct 22 22:12:06 2012 From: contact at nullivex.com (Bryan Tong) Date: Mon, 22 Oct 2012 16:12:06 -0600 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: As far as I know. There is no RFC based restrictions based on having those as usable IPs. We have been routing customers IP blocks on our network for a while and never had a problem with 0 or .255 as the assigned IP even with Microsoft Windows 2003 as the operating system. Im not sure how to fix your issue but I dont think its automatically disregarded by anyone that would seem silly. On Mon, Oct 22, 2012 at 4:07 PM, Paul Zugnoni wrote: > Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. > > Any experience or recommendations? Besides replace the ISA proxy?. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From matt at overloaded.net Mon Oct 22 22:18:16 2012 From: matt at overloaded.net (Matt Buford) Date: Mon, 22 Oct 2012 17:18:16 -0500 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni wrote: > Any experience or recommendations? Besides replace the ISA proxy?. Since > it's not mine to replace. Also curious whether there's an RFC recommending > against the use of .0 or .255 addresses for this reason. > Way back in the late 90's I tried this with a /23 dialup DHCP pool and quickly found that the .0 and .255 users couldn't get to some scattered web sites, though they seemed to be able to get to most of the Internet. However, a year or so ago I spun up an always-on Amazon ec2 instance with a static IP and was handed a .0 address. I still use this VM regularly and have not run into any problems with reachability for this address. From job at instituut.net Mon Oct 22 22:20:13 2012 From: job at instituut.net (Job Snijders) Date: Mon, 22 Oct 2012 17:20:13 -0500 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: <541D0E94-7F7A-4736-98A4-FB6EABC447EC@instituut.net> Hi Paul, On Oct 22, 2012, at 5:07 PM, Paul Zugnoni wrote: > Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. > > Any experience or recommendations? Besides replace the ISA proxy?. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. In the post-classfull routing world .0 and .255 should be normal IP addresses. CIDR was only recently defined (somewhere in 1993) so I understand it might take companies some time to adjust to this novel situation. Ok, enough snarkyness! Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ So yes, apparently problems like these still arise once in a while. My recommendation would be to fix the equipment and not blame it on .0 or .255. Kind regards, Job Snijders From dwhite at olp.net Mon Oct 22 22:22:31 2012 From: dwhite at olp.net (Dan White) Date: Mon, 22 Oct 2012 17:22:31 -0500 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: <20121022222231.GE5830@dan.olp.net> On 10/22/12?17:18?-0500, Matt Buford wrote: >On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni > wrote: > >> Any experience or recommendations? Besides replace the ISA proxy?. Since >> it's not mine to replace. Also curious whether there's an RFC recommending >> against the use of .0 or .255 addresses for this reason. >> > >Way back in the late 90's I tried this with a /23 dialup DHCP pool and >quickly found that the .0 and .255 users couldn't get to some scattered web >sites, though they seemed to be able to get to most of the Internet. > >However, a year or so ago I spun up an always-on Amazon ec2 instance with a >static IP and was handed a .0 address. I still use this VM regularly and >have not run into any problems with reachability for this address. I had a similar experience about 10 years ago, with DSL customers who had been assigned .0 or .255 addresses not able to reach some sites. -- Dan White From Fred.L.Templin at boeing.com Mon Oct 22 22:24:24 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 22 Oct 2012 15:24:24 -0700 Subject: IP tunnel MTU In-Reply-To: <20121022163626.GA50527@dyn.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> Message-ID: Hello, Several months ago, there was discussion on the list regarding IP tunnel maximum transmission unit (MTU). Since that time, it has been brought to my attention by members of my company's network operations staff that tunnel MTU is a very real problem they need to cope with on a daily basis - especially with the growing need to depend on both tunnels and tunnels-within-tunnels to track mobile devices. Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Unfortunately, both are known to be problematic in a non-trivial number of cases. The discussions on NANOG from back in the June timeframe resulted in "Operational Issues with Tunnel Maximum transmission Unit": https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ I would like to ask this group to now give this document a look and post your comments/thoughts/experiences. For example, has the tunnel MTU problem crept into daily operational considerations to the point that we should now at least be documenting it and preferably trying to do something about it? From talking to our staff, I believe the answer is yes but it would be good to have confirmation from others. Thanks in advance for your thoughts, Fred fred.l.templin at boeing.com From dhubbard at dino.hostasaurus.com Mon Oct 22 22:40:33 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 22 Oct 2012 18:40:33 -0400 Subject: Issues encountered with assigning .0 and .255 as usable addresses? References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: From: Paul Zugnoni [mailto:paul.zugnoni at jivesoftware.com] > > Curious whether it's commonplace to find systems that > automatically regard .0 and .255 IP addresses (ipv4) as > src/dst in packets as traffic that should be considered > invalid. When you have a pool of assignable addresses, you > should expect to see x.x.x.0 and x.x.x.255 in passing traffic > (ie. VIP or NAT pool, or subnets larger than /24). Yet I've > run into a commercial IP mgmt product and getting reports of > M$ ISA proxy that is specifically blocking traffic for an IP > ending in .0 or .255. > > Any experience or recommendations? Besides replace the ISA > proxy.... Since it's not mine to replace. Also curious whether > there's an RFC recommending against the use of .0 or .255 > addresses for this reason. > We're a web host and over the past 12 years we've randomly attempted to put non-critical customer sites on .0 and .255 addresses and found customers fairly consistently had problems accessing them. These would typically be sites for development, etc. where the customer was the only one accessing it and even then it has been a high percentage of failures. It is nearly always the customer's small biz / home office cheap-o router that is the issue even in this day and age but occassionally it has been the ISP as well. I haven't kept a list of vendors/isp's unfortunately so I don't have more useful information to offer you other than that it's still a problem. We still use those addresses for that purpose since they'd otherwise go to waste but most of the time it ends up being changed when the customer tries to access it from somewhere and can't. David From cperez at runcentral.com Mon Oct 22 22:16:00 2012 From: cperez at runcentral.com (Carlos M. Perez) Date: Mon, 22 Oct 2012 18:16:00 -0400 Subject: hotmail.com live.com admin needed Message-ID: <5085C5A0.7030206@runcentral.com> Hi, We're trying to resolve some delivery issues reported by hotmail users. Started happening a few weeks ago. Getting immediate NDRs, and the server that is supposed to receive the email has no records of attempts. The messages also don't match what the receiving server should be sending. The server(s) listed in the MX should receive all email without authentication, since it's a mail filtering service (Maxmail) === Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com Received-From-MTA: dns;SNT133-W53 Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 Final-Recipient: rfc822;administrator at xxxx.com Action: failed Status: 5.5.0 Diagnostic-Code: smtp;550 authentication required === Kindly contact me off-list. Thanks, -- Carlos M. Perez Runcentral, LLC From surfer at mauigateway.com Mon Oct 22 22:57:18 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Oct 2012 15:57:18 -0700 Subject: Issues encountered with assigning .0 and .255 as usable addresses? Message-ID: <20121022155718.7A07065E@resin09.mta.everyone.net> --- job at instituut.net wrote: From: Job Snijders > Curious whether it's commonplace to find systems that automatically regard > .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should > be considered invalid. When you have a pool of assignable addresses, you > should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT > pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product > and getting reports of M$ ISA proxy that is specifically blocking traffic for an > IP ending in .0 or .255. I used about a /15s worth of /23s for DHCP at a previous employer for 5 years (2005 - 2010) and they're still using them today years later. Never got one complaint AFAIK. I even got one of the .0 or .255 addresses for a while and never had trouble. This was discussed in detail a while back. Look in the archives. scott From jgreco at ns.sol.net Mon Oct 22 23:07:10 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 22 Oct 2012 18:07:10 -0500 (CDT) Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: <201210222307.q9MN7AIv063740@aurora.sol.net> > d be considered invalid. When you have a pool of assignable addresses, you = > should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N= > AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm= > t product and getting reports of M$ ISA proxy that is specifically blocking= > traffic for an IP ending in .0 or .255. To make a long story short: If it's a product you're considering buying, problems with .0 and .255 reflect on the competence of the product's designers. You can safely assume that there are many other Severely Broken Things too and move on to saner products. For general Internet use, there is a lot of gear out there that's ten or more years old. You should avoid using .0 and .255 addresses if you can avoid it, though it's a shame to waste valid IP space to accommodate the brokenness of someone else's stuff. Some of us park stuff on .0 and .255 addresses in order to motivate others to change. ... 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 Mon Oct 22 23:19:11 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 23 Oct 2012 10:19:11 +1100 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: Your message of "Mon, 22 Oct 2012 18:07:10 CDT." <201210222307.q9MN7AIv063740@aurora.sol.net> References: <201210222307.q9MN7AIv063740@aurora.sol.net> Message-ID: <20121022231911.5D0322A1E2EC@drugs.dv.isc.org> In message <201210222307.q9MN7AIv063740 at aurora.sol.net>, Joe Greco writes: > > d be considered invalid. When you have a pool of assignable addresses, you > = > > should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N > = > > AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm > = > > t product and getting reports of M$ ISA proxy that is specifically blocking > = > > traffic for an IP ending in .0 or .255. > > To make a long story short: > > If it's a product you're considering buying, problems with .0 and .255 > reflect on the competence of the product's designers. You can safely > assume that there are many other Severely Broken Things too and move on > to saner products. > > For general Internet use, there is a lot of gear out there that's ten or > more years old. You should avoid using .0 and .255 addresses if you can > avoid it, though it's a shame to waste valid IP space to accommodate the > brokenness of someone else's stuff. Ten year old equipment should be CIDR aware. It's not like it CIDR wasn't in wide spread using in 2002. > Some of us park stuff on .0 and .255 addresses in order to motivate > others to change. > > ... 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(CN > N) > With 24 million small businesses in the US alone, that's way too many apples. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jgreco at ns.sol.net Mon Oct 22 23:31:12 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 22 Oct 2012 18:31:12 -0500 (CDT) Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <20121022231911.5D0322A1E2EC@drugs.dv.isc.org> Message-ID: <201210222331.q9MNVCRk063996@aurora.sol.net> > Ten year old equipment should be CIDR aware. It's not like it CIDR > wasn't in wide spread using in 2002. And BCP38 has had sufficient time to be globally deployed. What's your point, again? ;-) I was pretty careful in trying to outline that it's still expected that there are defective products which even today will filter .0 and .255. This might be due to incompetence, or nobody having looked at the code in a dozen years, or other various faults. There is no central agency to validate gear against RFC, common use, and common sense, and from what I hear, even Cisco has maintained "classful" routing in useless contexts many years beyond what it should have. The painful difference between "should be CIDR aware" (we agree on this!) and "is actually CIDR compliant without amateur-hour mistakes" is a measurable distance, even today. ... 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 mysidia at gmail.com Tue Oct 23 00:23:54 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 22 Oct 2012 19:23:54 -0500 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: On 10/22/12, Paul Zugnoni wrote: [snip] > Any experience or recommendations? Besides replace the ISA proxy?. Since > it's not mine to replace. Also curious whether there's an RFC recommending > against the use of .0 or .255 addresses for this reason. ISA is old, and might not be supported anymore, unless you have an extended support contract. If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair. I don't recommend upgrading to TMG, either: although still supported, that was just discontinued. If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0 IP address, demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option. If the vendor can't or won't provide a resolution, then not only is the proxy server broken, but malfunctioning in a way that has an impact on network connectivity. I would consider its removal compulsory, as you never know, when a network resource, web site, e-mail server, etc. your org has a business critical need to access, or be accessed from; may be placed on .255 or .0 -- -JH From rdobbins at arbor.net Tue Oct 23 01:49:21 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 23 Oct 2012 01:49:21 +0000 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> Message-ID: <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: > Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate > the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Actually, you can set your tunnel MTU manually. For example, the typical MTU folks set for a GRE tunnel is 1476. This isn't a new issue; it's been around ever since tunneling technologies have been around, and tons have been written on this topic. Look at your various router/switch vendor Web sites, archives of this list and others, etc. So, it's been known about, dealt with, and documented for a long time. In terms of doing something about it, the answer there is a) to allow the requisite ICMP for PMTU-D to work to/through any networks within your span of administrative control and b) adjusting your own tunnel MTUs to appropriate values based upon experimentation. Enterprise endpoint networks are notorious for blocking *all* ICMP (as well as TCP/53 DNS) at their edges due to 'security' misinformation propagated by Confused Information Systems Security Professionals and their ilk. Be sure that your own network policies aren't part of the problem affecting your userbase, as well as anyone else with a need to communicate with properties on your network via tunnels. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jkrejci at usinternet.com Tue Oct 23 01:49:53 2012 From: jkrejci at usinternet.com (Justin Krejci) Date: Mon, 22 Oct 2012 20:49:53 -0500 Subject: Issues encountered with assigning .0 and .255 as usable addresses? Message-ID: <1350957003920-019-01412098.jkrejci.usinternet.com@[192.168.1.61]> And since owen has not yet mentioned it, consider something that supports having : in its address as well.? Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all.?Jimmy Hess wrote:On 10/22/12, Paul Zugnoni wrote: [snip] > Any experience or recommendations? Besides replace the ISA proxy?. Since > it's not mine to replace. Also curious whether there's an RFC recommending > against the use of .0 or .255 addresses for this reason. ISA is old, and might not be supported anymore, unless you have an extended support contract.?? If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair.???? I don't recommend upgrading to TMG, either:? although still supported, that was just discontinued. If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0? IP address,? demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option. If the vendor can't or won't provide a resolution,?? then? not only is the proxy server broken, but malfunctioning in a way?? that has an impact on network connectivity. I would consider its removal compulsory,? as you never know,? when a network resource, web site, e-mail server, etc. your org has a business? critical need to access,? or be accessed from;? may be placed on .255 or? .0 -- -JH From jabley at hopcount.ca Tue Oct 23 02:18:20 2012 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 22 Oct 2012 21:18:20 -0500 Subject: Semi-automated L3 interface DNS records In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BC431C41@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: On 2012-10-18, at 14:57, "Pedersen, Sean" wrote: > Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf ftp://ftp.isc.org/isc/toolmakers/ > We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. AS6461 once had the bulk of its reverse DNS auto-generated from awk scripts. It's the only way to travel. Joe From jabley at hopcount.ca Tue Oct 23 02:19:12 2012 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 22 Oct 2012 21:19:12 -0500 Subject: forward and reverse DNS (was: Please, talk me down.) In-Reply-To: <20121022163626.GA50527@dyn.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> Message-ID: <8925C74C-4E7D-467C-80EC-BE03FED01EFD@hopcount.ca> On 2012-10-22, at 11:36, Andrew Sullivan wrote: > On Mon, Oct 22, 2012 at 03:18:52PM +1100, Mark Andrews wrote: >> records are consistent. It is however good practice that these exist and >> are consistent. > > I will note that the IETF DNSOP WG was unable to agree even on that > latter claim. I will further note that just because dnsop can't agree on something doesn't mean that it's not worth agreeing on. Joe From mysidia at gmail.com Tue Oct 23 04:17:22 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 22 Oct 2012 23:17:22 -0500 Subject: forward and reverse DNS (was: Please, talk me down.) In-Reply-To: <8925C74C-4E7D-467C-80EC-BE03FED01EFD@hopcount.ca> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <8925C74C-4E7D-467C-80EC-BE03FED01EFD@hopcount.ca> Message-ID: On 10/22/12, Joe Abley wrote: > I will further note that just because dnsop can't agree on something doesn't > mean that it's not worth agreeing on. [snip] Some of the IETF WGs' members wouldn't be able to agree what color the sky appears to be on a clear sunny day. But it is common MTAs, to be configured to perform a check for Forward-Confirmed DNS, similar to the iprev authentication mechanism mentioned in RFC5451, except this is mandatory, and they refuse delivery. Many popular anti-spam solutions are implementing this out of the box, and common MTAs provide documentation recommending configurations that implement constraints such as these: 1. If a 'HELO' or 'EHLO' message is received, and there is no argument, the SMTP server will respond with a 5xx reject, even though it is technically allowed to have a HELO/EHLO without a hostnamr parameter specified. 2. If a 'HELO' or 'EHLO' message is received; the SMTP server will begin a forward DNS lookup on the hostname presented in the HELO/EHLO, and a Reverse DNS lookup on the connecting IP; it may initiate an outgoing connection to port 113 auth (Ident) on the connecting IP, in order to ask for a username to insert in message headers. a. If the forward DNS check on the HELO name, or the PTR query on the connecting IP fails to get a response. HELO fails with a 4xx reject. b. If either result in a NXDOMAIN response, HELO fails with a 5xx reject. c. If both succeed, a forward DNS lookup is started for the name found in the PTR response, and a 4xx reject upon lookup failure, or 5xx reject upon a NXDOMAIN response, or forward lookup response not matching the IP address of the client. o The "SMTP reject" might instead trigger a tarpitting mechanism. Some implementations currently accept the HELO and delay the SMTP reject by default until a later stage, such as RCPT TO, and/or cache the reject decision, to reduce the impact of multiple connection attempts. 3. If a 'RCPT TO' message is received, a 5xx smtp error is sent, unless a 'MAIL FROM' message has already been received and accepted, and the mailbox is a known local mailbox. 4. If a 'MAIL FROM' message is received, a 5xx smtp error is sent, unless a 'HELO' or 'EHLO' message has already been received and accepted. If the address referenced is not <>, then A DNS request is sent for forward lookup of the domain in the MAIL FROM, and SPF query/policy test on the envelope from address. If there is a SPF soft fail, a 4xx reject; SPF hard fail, or the domain does not exist, a SMTP 5xx reject. > Joe -- -JH From betty at newnog.org Tue Oct 23 06:15:42 2012 From: betty at newnog.org (Betty Burke ) Date: Tue, 23 Oct 2012 02:15:42 -0400 Subject: [NANOG-announce] vote.nanog.org Message-ID: NANOGers: If you have not yet joined NANOG as a member, become a member by visiting https://www.nanog.org/signup/ .. Members do play an important role in helping to sustain and direct NANOG. Note, voting for the 2011/2013 Board and Bylaw amendments will close at 5:00 PM CST on October 23, 2012. Should you have any questions or problems with joining or voting, send email to nanog-support at nanog.org or stop by the NANOG 56 Registration Desk... Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From adam.vitkovsky at swan.sk Tue Oct 23 07:30:42 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Tue, 23 Oct 2012 09:30:42 +0200 Subject: MP-BGP next hop tracking delay 0 Message-ID: <005f01cdb0f0$4e98d190$ebca74b0$@swan.sk> I was wondering whether you have some experience with setting of the next hop tracking delay value for BGP to 0 for critical changes please There's gonna be only a few prefixes registered with BGP so far, around 150+ adam From michiel at klaver.it Tue Oct 23 08:28:24 2012 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 23 Oct 2012 10:28:24 +0200 Subject: hotmail.com live.com admin needed In-Reply-To: <5085C5A0.7030206@runcentral.com> References: <5085C5A0.7030206@runcentral.com> Message-ID: <50865528.40009@klaver.it> Carlos, check the mail logs of your web-server, your domain might have a primary A-record pointing to something different than MX-records. When the MX servers do something like greylisting and bounce with a temp-code (4xx) hotmail servers will try alternative records (like @ IN A) and might find a listening mail-daemon at your webserver. At 23-10-2012 00:16, Carlos M. Perez wrote: > Hi, > > We're trying to resolve some delivery issues reported by hotmail users. > Started happening a few weeks ago. Getting immediate NDRs, and the > server that is supposed to receive the email has no records of > attempts. The messages also don't match what the receiving server > should be sending. The server(s) listed in the MX should receive all > email without authentication, since it's a mail filtering service (Maxmail) > > = > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com > Received-From-MTA: dns;SNT133-W53 > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 > > Final-Recipient: rfc822;administrator at xxxx.com > Action: failed > Status: 5.5.0 > Diagnostic-Code: smtp;550 authentication required > = > > Kindly contact me off-list. > > Thanks, > From ops.lists at gmail.com Tue Oct 23 08:37:04 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 23 Oct 2012 14:07:04 +0530 Subject: hotmail.com live.com admin needed In-Reply-To: <50865528.40009@klaver.it> References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> Message-ID: Falling back to A when there is an MX (especially after receiving any kind of SMTP response from the MX) is an RFC violation by the way (rfc 5321 section 5.1) Even then - this doesn't appear to be the case. The bounce below was generated entirely within Hotmail. From SNT133-WS53 (a hotmail webserver) to snt-omc3-s27.snt0.hotmail.com - which I believe is part of their outbound mail farm. That's where the bounce was generated. "Requires authentication" might be because whatever domain is being sent to was originally hosted on hotmail, and set to require authentication to relay out through hotmail's servers. --srs On Tuesday, October 23, 2012, Michiel Klaver wrote: > Carlos, > > check the mail logs of your web-server, your domain might have a primary > A-record pointing to something different than MX-records. When the MX > servers do something like greylisting and bounce with a temp-code (4xx) > hotmail servers will try alternative records (like @ IN A) and might find a > listening mail-daemon at your webserver. > > > At 23-10-2012 00:16, Carlos M. Perez wrote: > > Hi, > > > > We're trying to resolve some delivery issues reported by hotmail users. > > Started happening a few weeks ago. Getting immediate NDRs, and the > > server that is supposed to receive the email has no records of > > attempts. The messages also don't match what the receiving server > > should be sending. The server(s) listed in the MX should receive all > > email without authentication, since it's a mail filtering service > (Maxmail) > > > > = > > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com > > Received-From-MTA: dns;SNT133-W53 > > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 > > > > Final-Recipient: rfc822;administrator at xxxx.com > > Action: failed > > Status: 5.5.0 > > Diagnostic-Code: smtp;550 authentication required > > = > > > > Kindly contact me off-list. > > > > Thanks, > > > > -- --srs (iPad) From andy at strugglers.net Tue Oct 23 12:15:32 2012 From: andy at strugglers.net (Andy Smith) Date: Tue, 23 Oct 2012 12:15:32 +0000 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: <20121023121532.GT3867@bitfolk.com> Hello, On Mon, Oct 22, 2012 at 10:07:50PM +0000, Paul Zugnoni wrote: > Curious whether it's commonplace to find systems that > automatically regard .0 and .255 IP addresses (ipv4) as src/dst in > packets as traffic that should be considered invalid. On a separate note, one of my customers discovered over the weekend that if they bring up an all ones IPv6 address in their /64 (2001:db8:1:1:ffff:ffff:ffff:ffff) then they can't exchange traffic with stuff hosted at hetzner.de such as archives.postgresql.org or 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner. I found the same if I brought up an all ones address in any other /64 in the same /48 as well. Using ...ffff:ffff:ffff:fffe worked fine. I haven't had time to investigate further or tell them yet, though. Is that sort of thing common? Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting From cperez at runcentral.com Tue Oct 23 12:31:38 2012 From: cperez at runcentral.com (Carlos M. Perez) Date: Tue, 23 Oct 2012 08:31:38 -0400 Subject: hotmail.com live.com admin needed In-Reply-To: <50865528.40009@klaver.it> References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> Message-ID: <50868E2A.6080206@runcentral.com> Mike, I think this is exactly what is going on. The domains that are having issues have greylisting on with the spam filtering service and are hosted on a farm of hosting servers. We have blocked port 25 on the main hosting IP of the web server, and moved the built in mail server to listen on another IP. This appears to be working, or at least has been for almost 12 hours. The real question is why is hotmail/live the only system that apparently does this; which seems to be in contradiction to RFC, and how everyone else does it. The one thing that MS chooses to be different with... Thanks, Carlos M. Perez Runcentral, LLC On 10/23/2012 4:28 AM, Michiel Klaver wrote: > Carlos, > > check the mail logs of your web-server, your domain might have a primary > A-record pointing to something different than MX-records. When the MX > servers do something like greylisting and bounce with a temp-code (4xx) > hotmail servers will try alternative records (like @ IN A) and might find a > listening mail-daemon at your webserver. > > > At 23-10-2012 00:16, Carlos M. Perez wrote: >> Hi, >> >> We're trying to resolve some delivery issues reported by hotmail users. >> Started happening a few weeks ago. Getting immediate NDRs, and the >> server that is supposed to receive the email has no records of >> attempts. The messages also don't match what the receiving server >> should be sending. The server(s) listed in the MX should receive all >> email without authentication, since it's a mail filtering service (Maxmail) >> >> = >> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com >> Received-From-MTA: dns;SNT133-W53 >> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 >> >> Final-Recipient: rfc822;administrator at xxxx.com >> Action: failed >> Status: 5.5.0 >> Diagnostic-Code: smtp;550 authentication required >> = >> >> Kindly contact me off-list. >> >> Thanks, >> > > > From cperez at runcentral.com Tue Oct 23 12:31:20 2012 From: cperez at runcentral.com (Carlos M. Perez) Date: Tue, 23 Oct 2012 08:31:20 -0400 Subject: hotmail.com live.com admin needed In-Reply-To: References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> Message-ID: <50868E18.4090708@runcentral.com> Suresh, The affected domains have never been on hotmail, etc. We've actually held this domain/hosting for the past 14+ years on this particular domain. Yes, there is an RFC violation, and it's apparently due to the greylisting feature from the spam filtering. Carlos M. Perez Runcentral, LLC On 10/23/2012 4:37 AM, Suresh Ramasubramanian wrote: > Falling back to A when there is an MX (especially after receiving any > kind of SMTP response from the MX) is an RFC violation by the way (rfc > 5321 section 5.1) > > Even then - this doesn't appear to be the case. The bounce below was > generated entirely within Hotmail. From SNT133-WS53 (a hotmail > webserver) to snt-omc3-s27.snt0.hotmail.com > - which I believe is part of > their outbound mail farm. That's where the bounce was generated. > > "Requires authentication" might be because whatever domain is being > sent to was originally hosted on hotmail, and set to require > authentication to relay out through hotmail's servers. > > --srs > > On Tuesday, October 23, 2012, Michiel Klaver wrote: > > Carlos, > > check the mail logs of your web-server, your domain might have a > primary > A-record pointing to something different than MX-records. When the MX > servers do something like greylisting and bounce with a temp-code > (4xx) > hotmail servers will try alternative records (like @ IN A) and > might find a > listening mail-daemon at your webserver. > > > At 23-10-2012 00:16, Carlos M. Perez wrote: > > Hi, > > > > We're trying to resolve some delivery issues reported by hotmail > users. > > Started happening a few weeks ago. Getting immediate NDRs, and the > > server that is supposed to receive the email has no records of > > attempts. The messages also don't match what the receiving server > > should be sending. The server(s) listed in the MX should > receive all > > email without authentication, since it's a mail filtering > service (Maxmail) > > > > = > > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com > > > Received-From-MTA: dns;SNT133-W53 > > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 > > > > Final-Recipient: rfc822;administrator at xxxx.com > > Action: failed > > Status: 5.5.0 > > Diagnostic-Code: smtp;550 authentication required > > = > > > > Kindly contact me off-list. > > > > Thanks, > > > > > > -- > --srs (iPad) > > From ops.lists at gmail.com Tue Oct 23 12:49:20 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 23 Oct 2012 18:19:20 +0530 Subject: hotmail.com live.com admin needed In-Reply-To: <50868E2A.6080206@runcentral.com> References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> <50868E2A.6080206@runcentral.com> Message-ID: "authentication required" is a bizzarre error to return. Does it go away if you actually turn off graylisting for hotmail? On Tuesday, October 23, 2012, Carlos M. Perez wrote: > Mike, > > I think this is exactly what is going on. The domains that are having > issues have greylisting on with the spam filtering service and are > hosted on a farm of hosting servers. We have blocked port 25 on the > main hosting IP of the web server, and moved the built in mail server to > listen on another IP. This appears to be working, or at least has been > for almost 12 hours. > > The real question is why is hotmail/live the only system that apparently > does this; which seems to be in contradiction to RFC, and how everyone > else does it. The one thing that MS chooses to be different with... > > Thanks, > > Carlos M. Perez > Runcentral, LLC > > On 10/23/2012 4:28 AM, Michiel Klaver wrote: > > Carlos, > > > > check the mail logs of your web-server, your domain might have a primary > > A-record pointing to something different than MX-records. When the MX > > servers do something like greylisting and bounce with a temp-code (4xx) > > hotmail servers will try alternative records (like @ IN A) and might > find a > > listening mail-daemon at your webserver. > > > > > > At 23-10-2012 00:16, Carlos M. Perez wrote: > >> Hi, > >> > >> We're trying to resolve some delivery issues reported by hotmail users. > >> Started happening a few weeks ago. Getting immediate NDRs, and the > >> server that is supposed to receive the email has no records of > >> attempts. The messages also don't match what the receiving server > >> should be sending. The server(s) listed in the MX should receive all > >> email without authentication, since it's a mail filtering service > (Maxmail) > >> > >> = > >> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com > >> Received-From-MTA: dns;SNT133-W53 > >> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 > >> > >> Final-Recipient: rfc822;administrator at xxxx.com > >> Action: failed > >> Status: 5.5.0 > >> Diagnostic-Code: smtp;550 authentication required > >> = > >> > >> Kindly contact me off-list. > >> > >> Thanks, > >> > > > > > > > > > > > > > > -- --srs (iPad) From laidlaw at consecro.com Tue Oct 23 13:16:48 2012 From: laidlaw at consecro.com (Rob Laidlaw) Date: Tue, 23 Oct 2012 08:16:48 -0500 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: <20121023121532.GT3867@bitfolk.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: RFC 2526 reserves the last 128 host addresses in each subnet for anycast use. On Tue, Oct 23, 2012 at 7:15 AM, Andy Smith wrote: > Hello, > > On Mon, Oct 22, 2012 at 10:07:50PM +0000, Paul Zugnoni wrote: >> Curious whether it's commonplace to find systems that >> automatically regard .0 and .255 IP addresses (ipv4) as src/dst in >> packets as traffic that should be considered invalid. > > On a separate note, one of my customers discovered over the weekend > that if they bring up an all ones IPv6 address in their /64 > (2001:db8:1:1:ffff:ffff:ffff:ffff) then they can't exchange traffic > with stuff hosted at hetzner.de such as archives.postgresql.org or > 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner. > > I found the same if I brought up an all ones address in any other > /64 in the same /48 as well. Using ...ffff:ffff:ffff:fffe worked > fine. > > I haven't had time to investigate further or tell them yet, though. > > Is that sort of thing common? > > Cheers, > Andy > > -- > http://bitfolk.com/ -- No-nonsense VPS hosting > From sander at steffann.nl Tue Oct 23 13:34:50 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 23 Oct 2012 15:34:50 +0200 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: <8675AAFD-A29E-41CA-A105-59AE51C15DBA@steffann.nl> Hi, > RFC 2526 reserves the last 128 host addresses in each subnet for anycast use. But that would mean that the ...:fffe address also shouldn't work. Considering RFC 2526 then filtering those addresses when used as source address makes sense. - Sander PS: I'm in contact with a network engineer from Hetzner now to see what is really happening From Fred.L.Templin at boeing.com Tue Oct 23 14:07:17 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 23 Oct 2012 07:07:17 -0700 Subject: IP tunnel MTU In-Reply-To: <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: Hi Roland, > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Monday, October 22, 2012 6:49 PM > To: NANOG list > Subject: Re: IP tunnel MTU > > > On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: > > > Since tunnels always reduce the effective MTU seen by data packets due > to the encapsulation overhead, the only two ways to accommodate > > the tunnel MTU is either through the use of path MTU discovery or > through fragmentation and reassembly. > > Actually, you can set your tunnel MTU manually. > > For example, the typical MTU folks set for a GRE tunnel is 1476. Yes; I was aware of this. But, what I want to get to is setting the tunnel MTU to infinity. > This isn't a new issue; it's been around ever since tunneling technologies > have been around, and tons have been written on this topic. Look at your > various router/switch vendor Web sites, archives of this list and others, > etc. Sure. I've written a fair amount about it too over the span of the last ten years. What is new is that there is now a solution near at hand. > So, it's been known about, dealt with, and documented for a long time. In > terms of doing something about it, the answer there is a) to allow the > requisite ICMP for PMTU-D to work to/through any networks within your span > of administrative control and b) That does you no good if there is some other network further beyond your span of administrative control that does not allow the ICMP PTBs through. And, studies have shown this to be the case in a non-trivial number of instances. > b) adjusting your own tunnel MTUs to > appropriate values based upon experimentation. Adjust it down to what? 1280? Then, if your tunnel with the adjusted MTU enters another tunnel with its own adjusted MTU there is an MTU underflow that might not get reported if the ICMP PTB messages are lost. An alternative is to use IP fragmentation, but recent studies have shown that more and more operators are unconditionally dropping IPv6 fragments and IPv4 fragmentation is not an option due to wrapping IDs at high data rates. Nested tunnels-within-tunnels occur in operational scenarios more and more, and adjusting the MTU for only one tunnel in the nesting does you no good if there are other tunnels that adjust their own MTUs. > Enterprise endpoint networks are notorious for blocking *all* ICMP (as > well as TCP/53 DNS) at their edges due to 'security' misinformation > propagated by Confused Information Systems Security Professionals and > their ilk. Be sure that your own network policies aren't part of the > problem affecting your userbase, as well as anyone else with a need to > communicate with properties on your network via tunnels. Again, all an operator can control is that which is within their own administrative domain. That does no good for ICMPs that are lost beyond their administrative domain. Thanks - Fred fred.l.templin at boeing.com > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > From andy at strugglers.net Tue Oct 23 14:09:29 2012 From: andy at strugglers.net (Andy Smith) Date: Tue, 23 Oct 2012 14:09:29 +0000 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: <20121023140929.GU3867@bitfolk.com> Hi Rob, On Tue, Oct 23, 2012 at 08:16:48AM -0500, Rob Laidlaw wrote: > RFC 2526 reserves the last 128 host addresses in each subnet for anycast use. D'oh, I didn't even think to check for reserved addresses. Thanks. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting From mike at mikejones.in Tue Oct 23 15:18:43 2012 From: mike at mikejones.in (Mike Jones) Date: Tue, 23 Oct 2012 16:18:43 +0100 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: On 23 October 2012 14:16, Rob Laidlaw wrote: > RFC 2526 reserves the last 128 host addresses in each subnet for anycast use. IPv4 addresses ending in .0 and .255 can't be used either because the top and bottom addresses of a subnet are unusable. Why would hetzner be making such assumptions about what is and is not a valid address on a remote network? if you have a route to it then it is a valid address that you should be able to exchange packets with, any assumptions beyond that are almost certainly going to be wrong somewhere. Even if they did happen to correctly guess what sized subnets a remote network is using and what type of access media that remote network is using, I am pretty sure it would be wrong to assume that these addresses can't be accessed remotely considering the only address that is currently defined :) I really hope this is down to some kind of bug and not something someone did deliberately. - Mike From mstorck at voipgate.com Tue Oct 23 15:29:08 2012 From: mstorck at voipgate.com (Marc Storck) Date: Tue, 23 Oct 2012 15:29:08 +0000 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: Message-ID: >IPv4 addresses ending in .0 and .255 can't be used either because the >top and bottom addresses of a subnet are unusable. Only true if speaking of /24, but with the appearance of CIDR 19 years ago, this is not true anymore? The .255 and .0 in the "center" of a /23 are perfectly usable see an earlier post http://markmail.org/message/n2ctx6tw6kdcj2mr Regards, Marc Storck -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6079 bytes Desc: not available URL: From hvgeekwtrvl at gmail.com Tue Oct 23 17:39:08 2012 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 23 Oct 2012 10:39:08 -0700 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <1350957003920-019-01412098.jkrejci.usinternet.com@192.168.1.61> References: <1350957003920-019-01412098.jkrejci.usinternet.com@192.168.1.61> Message-ID: On Mon, Oct 22, 2012 at 6:49 PM, Justin Krejci wrote: > And since owen has not yet mentioned it, consider something that supports having : in its address as well. > > Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all. Jimmy Hess wrote:On 10/22/12, Paul Zugnoni wrote: > [snip] >> Any experience or recommendations? Besides replace the ISA proxy?. Since >> it's not mine to replace. Also curious whether there's an RFC recommending >> against the use of .0 or .255 addresses for this reason. > > ISA is old, and might not be supported anymore, unless you have an > extended support contract. If it's not supported anymore, then don't > be surprised if it has breakage you will not be able to repair. I > don't recommend upgrading to TMG, either: although still supported, > that was just discontinued. > > If ISA is refusing traffic to/from IPs ending in .0, then ISA is > either broken, or misconfigured. > Get a support case with the vendor, raise it as a critical issue -- > unable to pass traffic to critical infrastructure that ends with a > .255 or .0 IP address, demand that the vendor provide a resolution, > And explain that changing the IP address of the remote server is not an option. > > > If the vendor can't or won't provide a resolution, then not only is > the proxy server broken, > but malfunctioning in a way that has an impact on network connectivity. > > I would consider its removal compulsory, as you never know, when a > network resource, web site, e-mail server, etc. your org has a > business critical need to access, or be accessed from; may be > placed on .255 or .0 > > -- > -JH > this was also discussed back in August in this thread http://mailman.nanog.org/pipermail/nanog/2012-August/051290.html james From jeff.tantsura at ericsson.com Tue Oct 23 18:52:32 2012 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Tue, 23 Oct 2012 18:52:32 +0000 Subject: MP-BGP next hop tracking delay 0 In-Reply-To: <005f01cdb0f0$4e98d190$ebca74b0$@swan.sk> References: <005f01cdb0f0$4e98d190$ebca74b0$@swan.sk> Message-ID: <60DEDD93F5E54B4AB55647B8B6C748390753AB@EUSAAMB109.ericsson.se> Hi Adam, Works just fine on any relatively modern router. Cheers, Jeff -----Original Message----- From: Adam Vitkovsky [mailto:adam.vitkovsky at swan.sk] Sent: Tuesday, October 23, 2012 12:31 AM To: nanog at nanog.org Subject: MP-BGP next hop tracking delay 0 I was wondering whether you have some experience with setting of the next hop tracking delay value for BGP to 0 for critical changes please There's gonna be only a few prefixes registered with BGP so far, around 150+ adam From tore.anderson at redpill-linpro.com Tue Oct 23 20:00:53 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 23 Oct 2012 22:00:53 +0200 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <541D0E94-7F7A-4736-98A4-FB6EABC447EC@instituut.net> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <541D0E94-7F7A-4736-98A4-FB6EABC447EC@instituut.net> Message-ID: <5086F775.6060704@redpill-linpro.com> * Job Snijders > In the post-classfull routing world .0 and .255 should be normal IP > addresses. CIDR was only recently defined (somewhere in 1993) so I > understand it might take companies some time to adjust to this novel > situation. Ok, enough snarkyness! > > Quite recently a participant of the NLNOG RING had a problem related > to an .255 IP address. You can read more about it here: > https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ AIUI, that particular problem couldn't be blamed on lack of CIDR support either, as 91.218.150.255 is (was) a class A address. It would have had to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful pre-CIDR world. That said, it's rather common for people to believe that a /24 anywhere in the IPv4 address space is a ?class C? so I'm not really surprised. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From darrenoc at outlook.com Tue Oct 23 20:07:58 2012 From: darrenoc at outlook.com (Darren O'Connor) Date: Tue, 23 Oct 2012 21:07:58 +0100 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <5086F775.6060704@redpill-linpro.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com>, <541D0E94-7F7A-4736-98A4-FB6EABC447EC@instituut.net>, <5086F775.6060704@redpill-linpro.com> Message-ID: I purposely assigned myself a .0 and never had a problem using anything online, or going anywhere > Date: Tue, 23 Oct 2012 22:00:53 +0200 > From: tore.anderson at redpill-linpro.com > To: job at instituut.net > Subject: Re: Issues encountered with assigning .0 and .255 as usable addresses? > CC: nanog at nanog.org > > * Job Snijders > > > In the post-classfull routing world .0 and .255 should be normal IP > > addresses. CIDR was only recently defined (somewhere in 1993) so I > > understand it might take companies some time to adjust to this novel > > situation. Ok, enough snarkyness! > > > > Quite recently a participant of the NLNOG RING had a problem related > > to an .255 IP address. You can read more about it here: > > https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ > > AIUI, that particular problem couldn't be blamed on lack of CIDR support > either, as 91.218.150.255 is (was) a class A address. It would have had > to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful > pre-CIDR world. > > That said, it's rather common for people to believe that a /24 anywhere > in the IPv4 address space is a ?class C? so I'm not really surprised. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > From Fred.L.Templin at boeing.com Tue Oct 23 20:13:26 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 23 Oct 2012 13:13:26 -0700 Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: I realize that this is reaching way back, but you may want to have a look at the latest version of IRON: http://www.ietf.org/id/draft-templin-ironbis-12.txt IRON manages the internal routing systems for large virtual service provider networks. It deals with deaggregation and churn due to mobility internally, and does not expose the deaggregation and churn to the interdomain routing system. IRON is therefore an intradomain routing overlay network system, and can be used in conjunction with any interdomain routing system - including BGP and LISP. Thanks - Fred fred.l.templin at boeing.com > -----Original Message----- > From: Wes Felter [mailto:wmf at felter.org] > Sent: Tuesday, August 07, 2012 10:51 AM > To: nanog at nanog.org > Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) > > On 8/6/12 8:04 PM, Owen DeLong wrote: > > > The goal here was to make this as simple and cost-effective as the NAT- > based > > IPv4 solution currently in common use. There's no reason it can't be > exactly that. > > > > It does provide advantages over the NAT-based solution (sessions can > survive > > failover). > > What do people think about Fred Templin's IRON multihomed tunneling > approach (or LISP, I guess it can do it)? IRON should give you > multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming > traffic. It's less reliable than BGP in theory since you'd be virtually > single-homed to your IRON provider but that might be a worthwhile > tradeoff since staying up is pretty much their purpose in life. > > You'd have to pay a third provider to terminate your tunnels, but that > might be cheaper than paying an extra BGP tax to both of your physical > providers. IRON appears to require much less configuration than BGP and > it can also provide IPv6 over v4-only providers (good luck finding *two* > broadband providers in the same location that provide IPv6 and BGP). > > -- > Wes Felter > IBM Research - Austin > > > From morrowc.lists at gmail.com Tue Oct 23 20:20:02 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Oct 2012 16:20:02 -0400 Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: On Tue, Oct 23, 2012 at 4:13 PM, Templin, Fred L wrote: > I realize that this is reaching way back, but you may want > to have a look at the latest version of IRON: > > http://www.ietf.org/id/draft-templin-ironbis-12.txt > > IRON manages the internal routing systems for large virtual > service provider networks. It deals with deaggregation and > churn due to mobility internally, and does not expose the > deaggregation and churn to the interdomain routing system. > > IRON is therefore an intradomain routing overlay network > system, and can be used in conjunction with any interdomain > routing system - including BGP and LISP. someone should have brought this up in the ARMD working group... From ryan at ryansingel.net Tue Oct 23 21:52:07 2012 From: ryan at ryansingel.net (Ryan Singel) Date: Tue, 23 Oct 2012 14:52:07 -0700 Subject: Tech for blocking particular YouTube video - Wired.com question Message-ID: A colleague is working on a story that a particular country not to be named implemented technology to block a particular infamous riot-inducing video for a certain section of its populace. The questions are: 1) how hard is this to do at scale, 2) does it require DPI equipment and 3) is there a way to prove, from an end node, that it's happening? Off-list replies are fine, even better are folks willing to talk on record. I appreciate any help you can give. Ryan Singel Editor Wired Threat Level From mike.lyon at gmail.com Tue Oct 23 21:57:32 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 23 Oct 2012 14:57:32 -0700 Subject: Tech for blocking particular YouTube video - Wired.com question In-Reply-To: References: Message-ID: <1571761947918582016@unknownmsgid> And of course, we all know, it was the video that induced the riot... :) -mike Sent from my iPhone On Oct 23, 2012, at 14:53, Ryan Singel wrote: > A colleague is working on a story that a particular country not to be named > implemented technology to block a particular infamous riot-inducing video > for a certain section of its populace. > > The questions are: 1) how hard is this to do at scale, 2) does it require > DPI equipment and 3) is there a way to prove, from an end node, that it's > happening? > > Off-list replies are fine, even better are folks willing to talk on record. > > I appreciate any help you can give. > > Ryan Singel > Editor > Wired > Threat Level From froztbyte at froztbyte.net Tue Oct 23 22:20:32 2012 From: froztbyte at froztbyte.net (JP Viljoen) Date: Wed, 24 Oct 2012 00:20:32 +0200 Subject: Tech for blocking particular YouTube video - Wired.com question In-Reply-To: References: Message-ID: <14B600FF-0438-49A4-93BF-F2F7CDEBEB06@froztbyte.net> On 23 Oct 2012, at 11:52 PM, Ryan Singel wrote: > A colleague is working on a story that a particular country not to be named > implemented technology to block a particular infamous riot-inducing video > for a certain section of its populace. > > The questions are: 1) how hard is this to do at scale, 2) does it require > DPI equipment and 3) is there a way to prove, from an end node, that it's > happening? Challenge number one, push all your HTTP through one specific place. Not that hard. Choke all your traffic via a single routed path, WCCP or whatever it off from there. Just need equipment that can handle it. I'm going to make a slight assumption here on the level of traffic required, since it's likely not /that/ much in those warring regions. But if you need more traffic, you may exceed device limits, and then you might run into interesting state sharing issues on async routing (if the traffic out goes over one router (thus one cache), and back via another router/cache combo). If you have enough budget, it's doable. On question 2) I'd guess only if people were tunnelling HTTPS in normal HTTP. You could block HTTPS at port level, which would make YouTube (in normal operation) only be available over HTTP. You'd need tunnelling of whatever sort to get around this. 3) ?possibly. I would hazard to say it'd depend on how they're going about blocking in. To get back to 1: the moment you choke all the traffic through WCCP, you can hand it off to application servers that you maintain, and on those app servers you can then do whatever you like. This is how lots of semi-transparent/transparent caching is implemented. If you need more info, feel free to mail me directly. -J From will at loopfree.net Tue Oct 23 23:07:02 2012 From: will at loopfree.net (Will Orton) Date: Tue, 23 Oct 2012 16:07:02 -0700 Subject: Inter-domain OTN, does it happen in the real world? Message-ID: <20121023230702.GA27902@loopfree.net> Reading about OTN networks, I see that "IrDI" is specified to handle the case where one OTN network needs to connect to another natively with OTN signals. Is this done in the real world? Does OTN network operator A ever go to OTN network operator B and say, "I'd like to buy a OTU2 from city X to city Y on your long haul network (at buildings J and K where we can connect simply with short-distance SMF/1310 signals), and what TCM levels can you give me?" I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are OTU "lit" signals bought and sold wholesale this way too? Is there generally a price premium over the more normal client signals? -Will Orton From ops.lists at gmail.com Wed Oct 24 00:51:00 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 24 Oct 2012 06:21:00 +0530 Subject: Tech for blocking particular YouTube video - Wired.com question In-Reply-To: <14B600FF-0438-49A4-93BF-F2F7CDEBEB06@froztbyte.net> References: <14B600FF-0438-49A4-93BF-F2F7CDEBEB06@froztbyte.net> Message-ID: Most countries that implement a great firewall of $country model already do route all their international outbound traffic through a common gateway. Still others use the mechanism of sending a court order to all registered ISPs in the country asking them to block whichever URL it is. If that ISP uses a transparent proxy, or Cisco NBAR or whatever suits their individual architecture, that is entirely up to them And yes, at least some YouTube videos have gone viral within individual countries and triggered riots. Videos with content like, say, a group of people belonging to a particular religion demolishing and kicking down the country's equivalent to the tomb of the unknown soldier On Wednesday, October 24, 2012, JP Viljoen wrote: > On 23 Oct 2012, at 11:52 PM, Ryan Singel > > wrote: > > A colleague is working on a story that a particular country not to be > named > > implemented technology to block a particular infamous riot-inducing video > > for a certain section of its populace. > > > > The questions are: 1) how hard is this to do at scale, 2) does it require > > DPI equipment and 3) is there a way to prove, from an end node, that it's > > happening? > > Challenge number one, push all your HTTP through one specific place. Not > that hard. Choke all your traffic via a single routed path, WCCP or > whatever it off from there. Just need equipment that can handle it. I'm > going to make a slight assumption here on the level of traffic required, > since it's likely not /that/ much in those warring regions. But if you need > more traffic, you may exceed device limits, and then you might run into > interesting state sharing issues on async routing (if the traffic out goes > over one router (thus one cache), and back via another router/cache combo). > If you have enough budget, it's doable. > > On question 2) I'd guess only if people were tunnelling HTTPS in normal > HTTP. You could block HTTPS at port level, which would make YouTube (in > normal operation) only be available over HTTP. You'd need tunnelling of > whatever sort to get around this. > > 3) ?possibly. I would hazard to say it'd depend on how they're going about > blocking in. > > To get back to 1: the moment you choke all the traffic through WCCP, you > can hand it off to application servers that you maintain, and on those app > servers you can then do whatever you like. This is how lots of > semi-transparent/transparent caching is implemented. > > If you need more info, feel free to mail me directly. > > -J > -- --srs (iPad) From bedard.phil at gmail.com Wed Oct 24 01:25:56 2012 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 23 Oct 2012 21:25:56 -0400 Subject: Inter-domain OTN, does it happen in the real world? In-Reply-To: <20121023230702.GA27902@loopfree.net> References: <20121023230702.GA27902@loopfree.net> Message-ID: <12AA317E-A798-4A61-B1AE-47515AF8050A@gmail.com> Most telcos can provide an OTU2 client interface but there is no peering, they are just mapping directly to a wavelength or to OTU3/4. So it's transparent service. Phil On Oct 23, 2012, at 7:07 PM, Will Orton wrote: > Reading about OTN networks, I see that "IrDI" is specified to handle the case > where one OTN network needs to connect to another natively with OTN signals. > > Is this done in the real world? Does OTN network operator A ever go to OTN > network operator B and say, "I'd like to buy a OTU2 from city X to city Y on your > long haul network (at buildings J and K where we can connect simply with > short-distance SMF/1310 signals), and what TCM levels can you give me?" > > I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are OTU > "lit" signals bought and sold wholesale this way too? Is there generally a price > premium over the more normal client signals? > > -Will Orton > > From rodrick.brown at gmail.com Wed Oct 24 03:29:39 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Tue, 23 Oct 2012 23:29:39 -0400 Subject: Coded TCP Message-ID: "With coded TCP, blocks of packets are clumped together and then transformed into algebraic equations that describe the packets. If part of the message is lost, the receiver can solve the equation to derive the missing data. The process of solving the equations is simple and linear, meaning it doesn't require much processing on behalf of the router/smartphone/laptop. In testing, the coded TCP resulted in some dramatic improvements. MIT found that campus WiFi (2% packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5% packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps." http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf --RB From george.herbert at gmail.com Wed Oct 24 03:38:46 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 23 Oct 2012 20:38:46 -0700 Subject: Coded TCP In-Reply-To: References: Message-ID: <0D1D722E-15D8-4BE5-96BB-716D9C55CC70@gmail.com> Modeled with just simple FTP sessions? Ugh: they admitted to having MIT backbone packet traces to analyze, and then used that simple of a simulator... George William Herbert Sent from my iPhone On Oct 23, 2012, at 8:29 PM, Rodrick Brown wrote: > "With coded TCP, blocks of packets are clumped together and then > transformed into algebraic equations that describe the packets. If > part of the message is lost, the receiver can solve the equation to > derive the missing data. The process of solving the equations is > simple and linear, meaning it doesn't require much processing on > behalf of the router/smartphone/laptop. In testing, the coded TCP > resulted in some dramatic improvements. MIT found that campus WiFi (2% > packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5% > packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps." > > http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf > > --RB > From tvhawaii at shaka.com Wed Oct 24 03:57:12 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 23 Oct 2012 17:57:12 -1000 Subject: Coded TCP References: <0D1D722E-15D8-4BE5-96BB-716D9C55CC70@gmail.com> Message-ID: <87A8B2E4B2A14323A033151E2C9FAC87@owner59e1f1502> George Herbert wrote: > Modeled with just simple FTP sessions? > > Ugh: they admitted to having MIT backbone packet traces to analyze, and then used that simple of a simulator... The practical benefits of the technology, known as coded TCP, were seen on a recent test run on a New York-to-Boston Acela train, notorious for poor connectivity. By increasing their available bandwidth-the amount of data that can be relayed in a given period of time-Medard and students were able to watch blip-free YouTube videos while some other passengers struggled to get online. "They were asking us 'How did you do that?' and we said 'We're engineers!' " she jokes. More here: http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20121023 From george.herbert at gmail.com Wed Oct 24 04:35:24 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 23 Oct 2012 21:35:24 -0700 Subject: Coded TCP In-Reply-To: <87A8B2E4B2A14323A033151E2C9FAC87@owner59e1f1502> References: <0D1D722E-15D8-4BE5-96BB-716D9C55CC70@gmail.com> <87A8B2E4B2A14323A033151E2C9FAC87@owner59e1f1502> Message-ID: <93F056D6-6FF5-4425-AF56-D374FC586B33@gmail.com> I understand and believe in the value of erasure coding, though I want to see the latency effects here. But that model was very detailed view into an overly simple (to the point of operationally unrealistic) model. Bad example, for a research paper. George William Herbert Sent from my iPhone On Oct 23, 2012, at 8:57 PM, "Michael Painter" wrote: > George Herbert wrote: >> Modeled with just simple FTP sessions? >> >> Ugh: they admitted to having MIT backbone packet traces to analyze, and then used that simple of a simulator... > > > The practical benefits of the technology, known as coded TCP, were seen on a recent test run on a New York-to-Boston Acela train, notorious for poor connectivity. By increasing their available bandwidth-the amount of data that can be relayed in a given period of time-Medard and students were able to watch blip-free YouTube videos while some other passengers struggled to get online. "They were asking us 'How did you do that?' and we said 'We're engineers!' " she jokes. > > More here: > http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20121023 > From jmaslak at antelope.net Wed Oct 24 04:52:48 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 23 Oct 2012 22:52:48 -0600 Subject: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?) In-Reply-To: References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: On Tue, Oct 23, 2012 at 9:18 AM, Mike Jones wrote: > IPv4 addresses ending in .0 and .255 can't be used either because the > top and bottom addresses of a subnet are unusable. > > Why would hetzner be making such assumptions about what is and is not > a valid address on a remote network? if you have a route to it then it > is a valid address that you should be able to exchange packets with, > any assumptions beyond that are almost certainly going to be wrong > somewhere. As to why: I suspect they don't know either. I wouldn't be surprised if it was someone's misguided attempt years ago to stop smurf amplification attacks, long since forgotten. I'm not saying it's a good idea (it's not), just why I suspect someone would do this. From mohta at necom830.hpcl.titech.ac.jp Wed Oct 24 06:35:41 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 24 Oct 2012 15:35:41 +0900 Subject: Coded TCP In-Reply-To: References: Message-ID: <50878C3D.7060506@necom830.hpcl.titech.ac.jp> (2012/10/24 12:29), Rodrick Brown wrote: > "With coded TCP, blocks of packets are clumped together and then > transformed into algebraic equations that describe the packets. If > part of the message is lost, the receiver can solve the equation to > derive the missing data. Don't do that. > MIT found that campus WiFi (2% > packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5% > packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps." If everyone start using TCP with FEC to tolerate 20% of packet loss with 30% FEC overhead, it will make congestion more severe that more than 20% of packets will be dropped and effective speed share of each TCP will be decreased by 30%. The proper approach against lossy liks is to have link local retransmissions or FEC. Masataka Ohta From michiel at klaver.it Wed Oct 24 07:00:53 2012 From: michiel at klaver.it (Michiel Klaver) Date: Wed, 24 Oct 2012 09:00:53 +0200 Subject: hotmail.com live.com admin needed In-Reply-To: References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> <50868E2A.6080206@runcentral.com> Message-ID: <50879225.5010806@klaver.it> As mentioned before, check the mail-logs at your webserver, you'll find this "authentication required" message logged there as response to the hotmail servers trying to relay mail to that webserver. At 23-10-2012 14:49, Suresh Ramasubramanian wrote: > "authentication required" is a bizzarre error to return. > > Does it go away if you actually turn off graylisting for hotmail? > > On Tuesday, October 23, 2012, Carlos M. Perez wrote: > >> Mike, >> >> I think this is exactly what is going on. The domains that are having >> issues have greylisting on with the spam filtering service and are >> hosted on a farm of hosting servers. We have blocked port 25 on the >> main hosting IP of the web server, and moved the built in mail server to >> listen on another IP. This appears to be working, or at least has been >> for almost 12 hours. >> >> The real question is why is hotmail/live the only system that apparently >> does this; which seems to be in contradiction to RFC, and how everyone >> else does it. The one thing that MS chooses to be different with... >> >> Thanks, >> >> Carlos M. Perez >> Runcentral, LLC >> >> On 10/23/2012 4:28 AM, Michiel Klaver wrote: >>> Carlos, >>> >>> check the mail logs of your web-server, your domain might have a primary >>> A-record pointing to something different than MX-records. When the MX >>> servers do something like greylisting and bounce with a temp-code (4xx) >>> hotmail servers will try alternative records (like @ IN A) and might >> find a >>> listening mail-daemon at your webserver. >>> >>> >>> At 23-10-2012 00:16, Carlos M. Perez wrote: >>>> Hi, >>>> >>>> We're trying to resolve some delivery issues reported by hotmail users. >>>> Started happening a few weeks ago. Getting immediate NDRs, and the >>>> server that is supposed to receive the email has no records of >>>> attempts. The messages also don't match what the receiving server >>>> should be sending. The server(s) listed in the MX should receive all >>>> email without authentication, since it's a mail filtering service >> (Maxmail) >>>> >>>> = >>>> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com >>>> Received-From-MTA: dns;SNT133-W53 >>>> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 >>>> >>>> Final-Recipient: rfc822;administrator at xxxx.com >>>> Action: failed >>>> Status: 5.5.0 >>>> Diagnostic-Code: smtp;550 authentication required >>>> = >>>> >>>> Kindly contact me off-list. >>>> >>>> Thanks, >>>> >>> >>> >>> >> >> >> >> >> >> >> >> > From daniel.crompton at gmail.com Wed Oct 24 07:39:17 2012 From: daniel.crompton at gmail.com (=?ISO-8859-1?Q?Dani=EBl_W=2E_Crompton?=) Date: Wed, 24 Oct 2012 09:39:17 +0200 Subject: Coded TCP In-Reply-To: <50878C3D.7060506@necom830.hpcl.titech.ac.jp> References: <50878C3D.7060506@necom830.hpcl.titech.ac.jp> Message-ID: On 24 October 2012 08:35, Masataka Ohta wrote: > (2012/10/24 12:29), Rodrick Brown wrote: > > "With coded TCP, blocks of packets are clumped together and then > > transformed into algebraic equations that describe the packets. If > > part of the message is lost, the receiver can solve the equation to > > derive the missing data. > > Don't do that. > This reads much like Reed-Solomon Error Correction[1], although it is a good way to reconstruct lost data it introduces a network overhead and a performance impact due to the reconstruction. The analysis states: "*the receiver will receive at least 10 linear combinations to decode the original 10 packets.*" Which reads to me as we need 10 packets of error correction data to reconstruct 10 packets. The only advantage I can see here, is that it would outperform UDP. :) D. 1. http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction -- blaze your trail -- Dani?l W. Crompton http://specialbrands.net/ From eugen at leitl.org Wed Oct 24 08:04:53 2012 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 24 Oct 2012 10:04:53 +0200 Subject: One big cluster: How CloudFlare launched 10 data centers in 30 days Message-ID: <20121024080453.GF9750@leitl.org> http://arstechnica.com/information-technology/2012/10/one-big-cluster-how-cloudflare-launched-10-data-centers-in-30-days/ One big cluster: How CloudFlare launched 10 data centers in 30 days With high-performance computing, "pixie-booting" servers a half-world away. by Sean Gallagher - Oct 19 2012, 0:13am -200 Big Data Cloud Open Source Supercomputing The Web The inside of Equinix's co-location facility in San Jose?the home of CloudFlare's primary data center. Photo: Peter McCollough/Wired.com On August 22, CloudFlare, a content delivery network, turned on a brand new data center in Seoul, Korea?the last of ten new facilities started across four continents in a span of thirty days. The Seoul data center brought CloudFlare's number of data centers up to 23, nearly doubling the company's global reach?a significant feat in itself for a company of just 32 employees. But there was something else relatively significant about the Seoul data center and the other 9 facilities set up this summer: despite the fact that the company owned every router and every server in their racks, and each had been configured with great care to handle the demands of CloudFlare's CDN and security services, no one from CloudFlare had ever set foot in them. All that came from CloudFlare directly was a six-page manual instructing facility managers and local suppliers on how to rack and plug in the boxes shipped to them. "We have nobody stationed in Stockholm or Seoul or Sydney, or a lot of the places that we put these new data centers," CloudFlare CEO Matthew Prince told Ars. "In fact, no CloudFlare employees have stepped foot in half of the facilities where we've launched." The totally remote-controlled data center approach used by the company is one of the reasons that CloudFlare can afford to provide its services for free to most of its customers?and still make a 75 percent profit margin. In the two years since its launch, the content delivery network and denial-of-service protection company has helped keep all sorts of sites online during global attacks, both famous and infamous?including recognition from both Davos and LulzSec. And all that attention has amounted to Yahoo-sized traffic?the CloudFlare service has handled over 581 billion pageviews since its launch. Yet CloudFlare does all this without the sort of Domain Name Service "black magic" that Akamai and other content delivery networks use to forward-position content?and with only 32 employees. To reach that level of efficiency, CloudFlare has done some black magic of a different sort, relying on open-source software from the realm of high-performance computing, storage tricks from the world of "big data," a bit of network peering arbitrage and clever use of a core Internet routing technology. In the process, it has created an ever-expanding army of remote-controlled service points around the globe that can eat 60-gigabit-per-second distributed denial of service attacks for breakfast. Routing with Anycast CloudFlare's CDN is based on Anycast, a standard defined in the Border Gateway Protocol?the routing protocol that's at the center of how the Internet directs traffic. Anycast is part of how BGP supports the multi-homing of IP addresses, in which multiple routers connect a network to the Internet; through the broadcasts of IP addresses available through a router, other routers determine the shortest path for network traffic to take to reach that destination. Using Anycast means that CloudFlare makes the servers it fronts appear to be in many places, while only using one IP address. "If you do a traceroute to Metallica.com (a CloudFlare customer), depending on where you are in the world, you would hit a different data center," Prince said. "But you're getting back the same IP address." That means that as CloudFlare adds more data centers, and those data centers advertise the IP addresses of the websites that are fronted by the service, the Internet's core routers automatically re-map the routes to the IP addresses of the sites. There's no need to do anything special with the Domain Name Service to handle load-balancing of network traffic to sites other than point the hostname for a site at CloudFlare's IP address. It also means that when a specific data center needs to be taken down for an upgrade or maintenance (or gets knocked offline for some other reason), the routes can be adjusted on the fly. That makes it much harder for distributed denial of service attacks to go after servers behind CloudFlare's CDN network; if they're geographically widespread, the traffic they generate gets spread across all of CloudFlare's data centers?as long as the network connections at each site aren't overcome. In September, Prince said, "there was a brand new botnet out there launching big attacks, and it targeted one of our customers. It generated 65 gigabits per second of traffic hitting our network. But none of that traffic was focused in one place?it was split fairly evenly across our 23 data centers, so each of those facilities only had to deal with about 3 gigs of traffic. That's much more manageable." Net-rich, power-poor Making CloudFlare's approach work requires that it put its networks as close as possible to the core routers of the Internet?at least in terms of network hops. While companies like Google, Facebook, Microsoft, and Yahoo have gone to great lengths to build their own custom data centers in places where power is cheap and where they can take advantage of the economies of scale, CloudFlare looks to use existing facilities that "your network traffic would be passing through even if you weren't using our service," Prince said. As a result, the company's "data centers" are usually at most a few racks of hardware, installed at co-location facilities that are major network exchange points. Prince said that most of his company's data centers are set up at Equinix IBX co-location facilities in the US, including CloudFlare's primary facility in San Jose?a facility also used by Google and other major cloud players as an on-ramp to the Internet. CloudFlare looks for co-location facilities with the same sort of capabilities wherever it can. But these sorts of facilities tend to be older, without the kind of power distribution density that a custom-built data center would have. "That means that to get as much compute power as possible into any given rack, we're spending a lot of time paying attention to what power decisions we make," Prince said. The other factor driving what goes into those racks is the need to maximize the utilization of CloudFlare's outbound Internet connections. CloudFlare buys its bandwidth wholesale from network transit providers, committing to a certain level of service. "We're paying for that no matter what," Prince said, "so it's optimal to fill that pipe up." That means that the computing power of CloudFlare's servers is less of a priority than networking and cache input/output and power consumption. And since CloudFlare depends heavily on the facility providers overseas or other partners to do hardware installations and swap-outs, the company needed to make its servers as simple as possible to install?bringing it down to that six-page manual. To make that possible, CloudFlare's engineering team drew on experience and technology from the high-performance computing world. The magical pixie-booted data center "A lot of our team comes from the HPC space," Prince said. "They include people who built HPC networks for the Department of Energy, where they have an 80 thousand node cluster, and had to figure out how to get 80,000 computers, fit them into one space, cable them in a really reliable way, and make sure that you can manage them from a single location." One of the things that CloudFlare brought over from the team's DoE experience was the Perceus Provisioning System, an open-source provisioning system for Linux used by DoE for its HPC environments. All of CloudFlare's servers are "pixie-booted" (using a Preboot eXecution Environment, or PXE) across a virtual private network between data centers; servers are delivered with no operating system or configuration whatsoever, other than a bootloader that calls back to Perceus for provisioning. "The servers come from whatever equipment vendor we buy them from completely bare," Prince said. "All we get from them is the MAC address." CloudFlare's servers run on a custom-built Linux distribution based on Debian. For security purposes, the servers are "statelessly" provisioned with Perceus?that is, the operating system is loaded completely in RAM. The mass storage on CloudFlare servers (which is universally based on SSD drives) is used exclusively for caching data from clients' sites. The gear deployed to data centers that gets significant pre-installation attention from CloudFlare's engineers is the routers?primarily supplied by Juniper Networks, which works with CloudFlare to preconfigure them before being shipped to new data centers. Part of the configuration is to create virtual network connections over the Internet to the other CloudFlare data centers, which allows each data center to use its nearest peer to pull software from during provisioning and updating. "When we booted up Vienna, for example," said Prince, "the closest data center was Frankfurt, so we used the Frankfurt facility to boot the new Vienna facility." One server in Vienna was booted first as the "master node," with provisioning instructions for each of the other machines. Once the servers are all provisioned and loaded, "they call back to our central facility (in San Jose) and say, 'Here are our MAC addresses, what do you need us to do?'" Once the machines have passed a final set of tests, each gets designated with an operational responsibility: acting as a proxy for Web requests to clients' servers, managing the cache of content to speed responses, DNS and logging services. Each of those services can be run on any server in the stack and step up to take over a service if one of its comrades fails. Caching and hashing Caching is part of the job for every server in each CloudFlare facility, and being able to scale up the size of the cache is another reason for the modular nature of how the company thinks of servers. Rather than storing cached webpage objects in a traditional database or file system, CloudFlare uses a hash-based database that works in a fashion similar to "NoSQL" databases like 10gen's MongoDB and Amazon's Dynamo storage system. When a request for a webpage comes in for the first time, CloudFlare retrieves the site contents. A consistent hashing algorithm in CloudFlare's caching engine then converts the URL used to call each element into a value, which is used as the key under which the content is stored locally at each data center. Each server in the stack is assigned a range of hashes to store content for, and subsequent requests for the content are routed to the appropriate server for that cache. Unlike most database applications, the cache stored at each CloudFlare facility has an undefined expiration date?and because of the nature of those facilities, it isn't a simple matter to add more storage. To keep the utilization level of installed storage high, the cache system simply purges older cache data when it needs to store new content. The downside of the hash-based cache's simplicity is that it has no built-in logging system to track content. CloudFlare can't tell customers which data centers have copies of which content they've posted. "A customer will ask me, 'Tell me all of the files you have in cache,'" Prince said. "For us, all we know is there are a whole bunch of hashes sitting on a disk somewhere?we don't keep track of which object belongs to what site." The upside, however, is that the system has a very low overhead as a result and can retrieve site content quickly and keep those outbound pipes full. And when you're scaling a 32-person company to fight the speed of light worldwide, it helps to keep things as simple as possible. From bmanning at vacation.karoshi.com Tue Oct 23 23:03:55 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 23 Oct 2012 23:03:55 +0000 Subject: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <5086F775.6060704@redpill-linpro.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <541D0E94-7F7A-4736-98A4-FB6EABC447EC@instituut.net> <5086F775.6060704@redpill-linpro.com> Message-ID: <20121023230355.GA28249@vacation.karoshi.com.> ok... so lets look at some space here. 98.32.0.0/22 98.32.0.0/32 is clearly on the unusable boundary. what about 98.32.0.255/32 & 98.32.1.0/32 ??? 98.32.4.255/32 is also clearly on the unusable boundary... UNTIL the delegation moves from a /22 to a /21. Then its usable. clear? thought so. /bill On Tue, Oct 23, 2012 at 10:00:53PM +0200, Tore Anderson wrote: > * Job Snijders > > > In the post-classfull routing world .0 and .255 should be normal IP > > addresses. CIDR was only recently defined (somewhere in 1993) so I > > understand it might take companies some time to adjust to this novel > > situation. Ok, enough snarkyness! > > > > Quite recently a participant of the NLNOG RING had a problem related > > to an .255 IP address. You can read more about it here: > > https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ > > AIUI, that particular problem couldn't be blamed on lack of CIDR support > either, as 91.218.150.255 is (was) a class A address. It would have had > to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful > pre-CIDR world. > > That said, it's rather common for people to believe that a /24 anywhere > in the IPv4 address space is a +class C; so I'm not really surprised. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ From sander at steffann.nl Wed Oct 24 11:26:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 24 Oct 2012 13:26:59 +0200 Subject: Issues encountered with assigning all ones IPv6 /64 address? In-Reply-To: <20121023121532.GT3867@bitfolk.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <20121023121532.GT3867@bitfolk.com> Message-ID: Hi, > On a separate note, one of my customers discovered over the weekend > that if they bring up an all ones IPv6 address in their /64 > (2001:db8:1:1:ffff:ffff:ffff:ffff) then they can't exchange traffic > with stuff hosted at hetzner.de such as archives.postgresql.org or > 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner. > > I found the same if I brought up an all ones address in any other > /64 in the same /48 as well. Using ...ffff:ffff:ffff:fffe worked > fine. > > I haven't had time to investigate further or tell them yet, though. I discussed this with Hetzner and it seems to be a bug in JunOS 10.3R1.9. - Sander From cb.list6 at gmail.com Wed Oct 24 13:37:22 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 24 Oct 2012 06:37:22 -0700 Subject: Coded TCP In-Reply-To: References: <50878C3D.7060506@necom830.hpcl.titech.ac.jp> Message-ID: On Oct 24, 2012 12:40 AM, "Dani?l W. Crompton" wrote: > > On 24 October 2012 08:35, Masataka Ohta wrote: > > > (2012/10/24 12:29), Rodrick Brown wrote: > > > "With coded TCP, blocks of packets are clumped together and then > > > transformed into algebraic equations that describe the packets. If > > > part of the message is lost, the receiver can solve the equation to > > > derive the missing data. > > > > Don't do that. > > > > This reads much like Reed-Solomon Error Correction[1], although it is a > good way to reconstruct lost data it introduces a network overhead and a > performance impact due to the reconstruction. The analysis states: "*the > receiver will receive at least 10 linear combinations to decode the > original 10 packets.*" Which reads to me as we need 10 packets of error > correction data to reconstruct 10 packets. > > The only advantage I can see here, is that it would outperform UDP. :) > > D. > Further, FEC and HARQ are already part of many L1 and L2 networks.... Including UMTS and LTE. ... So this is yet another cross layer optimization issue... Not solving the "spectrum crunch" .... But that makes good copy. Folks are much better off spending their time looking into SCTP IMHO. CB > > 1. http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction > > -- > blaze your trail > > -- > Dani?l W. Crompton > > > > > http://specialbrands.net/ > > < http://www.linkedin.com/in/redhat> From bernie.listsub at landmark.coop Wed Oct 24 14:20:09 2012 From: bernie.listsub at landmark.coop (bernie listsub) Date: Wed, 24 Oct 2012 14:20:09 +0000 Subject: Windstream outage in WI and MI? Message-ID: We're seeing multiple sites in our MPLS that are down, and got word from our Windstream sales rep that there was a fiber cut affecting WI and MI. The NOC is either ringing busy or giving a high call volume greeting. Anyone else affected or know more? -Bernie ================================ Nick "Bernie" Bernhardt nick.bernhardt at landmark.coop ================================ "We are a COOPERATIVE business dedicated to providing rural and urban customers with the HIGHEST QUALITY products and services.? We will enhance our producers' profitability, EXCEED customer expectations and keep our cooperative financially STRONG." From dwhite at olp.net Wed Oct 24 14:22:50 2012 From: dwhite at olp.net (Dan White) Date: Wed, 24 Oct 2012 09:22:50 -0500 Subject: Windstream outage in WI and MI? In-Reply-To: References: Message-ID: <20121024142250.GC7184@dan.olp.net> A voice outage has been reported on the outages mailing list: https://puck.nether.net/pipermail/outages/2012-October/004619.html On 10/24/12?14:20?+0000, bernie listsub wrote: >We're seeing multiple sites in our MPLS that are down, and got word from our Windstream sales rep that there was a fiber cut affecting WI and MI. The NOC is either ringing busy or giving a high call volume greeting. > >Anyone else affected or know more? > >-Bernie > >================================ >Nick "Bernie" Bernhardt >nick.bernhardt at landmark.coop >================================ >"We are a COOPERATIVE business dedicated to providing rural and urban customers with the HIGHEST QUALITY products and services.? We will enhance our producers' profitability, EXCEED customer expectations and keep our cooperative financially STRONG." > > > > -- Dan White From kin-wei.lee at hp.com Wed Oct 24 16:37:36 2012 From: kin-wei.lee at hp.com (Lee, Steven (Network Consulting Malaysia)) Date: Wed, 24 Oct 2012 16:37:36 +0000 Subject: SCTP Firewall with multi-homing support Message-ID: <392A074AA4FF0A459B45BFE734977F6918175682@G2W2535.americas.hpqcorp.net> Hi all, has anyone have the experience on SCTP firewall to protect the SIGTRAN communication between local mobile operator and roaming partner? If yes, please contact me offline. Thanks and regards, kinwei From adrian at olddog.co.uk Wed Oct 24 17:22:52 2012 From: adrian at olddog.co.uk (Adrian Farrel) Date: Wed, 24 Oct 2012 18:22:52 +0100 Subject: Inter-domain OTN, does it happen in the real world? In-Reply-To: <20121023230702.GA27902@loopfree.net> References: <20121023230702.GA27902@loopfree.net> Message-ID: <12e001cdb20c$335b5e30$9a121a90$@olddog.co.uk> Will, I think you also need to consider the case where one operator runs more than one network. This can happen because of acquisition or administrative structure. I regret it might also happen because of vendor equipment compatibility/lock-in issues. Cheers, Adrian > -----Original Message----- > From: Will Orton [mailto:will at loopfree.net] > Sent: 24 October 2012 00:07 > To: nanog at nanog.org > Subject: Inter-domain OTN, does it happen in the real world? > > Reading about OTN networks, I see that "IrDI" is specified to handle the case > where one OTN network needs to connect to another natively with OTN signals. > > Is this done in the real world? Does OTN network operator A ever go to OTN > network operator B and say, "I'd like to buy a OTU2 from city X to city Y on your > long haul network (at buildings J and K where we can connect simply with > short-distance SMF/1310 signals), and what TCM levels can you give me?" > > I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are OTU > "lit" signals bought and sold wholesale this way too? Is there generally a price > premium over the more normal client signals? > > -Will Orton From dot at dotat.at Wed Oct 24 17:25:02 2012 From: dot at dotat.at (Tony Finch) Date: Wed, 24 Oct 2012 18:25:02 +0100 Subject: hotmail.com live.com admin needed In-Reply-To: References: <5085C5A0.7030206@runcentral.com> <50865528.40009@klaver.it> <50868E2A.6080206@runcentral.com> Message-ID: Suresh Ramasubramanian wrote: > "authentication required" is a bizzarre error to return. It's fairly normal error from an Exchange server when the client is trying to relay to a domain that the server doesn't host and when the server doesn't allow the client to relay. Sounds like an internal misconfiguration in this case. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley at hopcount.ca Wed Oct 24 18:15:20 2012 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 24 Oct 2012 13:15:20 -0500 Subject: One big cluster: How CloudFlare launched 10 data centers in 30 days In-Reply-To: <20121024080453.GF9750@leitl.org> References: <20121024080453.GF9750@leitl.org> Message-ID: <76455E5F-FFD8-47DA-BEF6-3B46057A3671@hopcount.ca> On 2012-10-24, at 3:04, Eugen Leitl wrote: > http://arstechnica.com/information-technology/2012/10/one-big-cluster-how-cloudflare-launched-10-data-centers-in-30-days/ > > One big cluster: How CloudFlare launched 10 data centers in 30 days In a similar vein, Dave Knight talked at RIPE 64 about how we deployed L-Root in 60 locations in March. Widespread deployment with zero travel is highly recommended. https://ripe64.ripe.net/presentations/135-dknight-lroot-dnswg-ripe64.pdf Joe From askoorb+nanog at gmail.com Wed Oct 24 19:44:30 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Wed, 24 Oct 2012 20:44:30 +0100 Subject: hotmail.com live.com admin needed In-Reply-To: <5085C5A0.7030206@runcentral.com> References: <5085C5A0.7030206@runcentral.com> Message-ID: Hello, On Mon, Oct 22, 2012 at 11:16 PM, Carlos M. Perez wrote: > Hi, > > We're trying to resolve some delivery issues reported by hotmail users. > Started happening a few weeks ago. > === > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com > Received-From-MTA: dns;SNT133-W53 > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 > > Final-Recipient: rfc822;administrator at xxxx.com > Action: failed > Status: 5.5.0 > Diagnostic-Code: smtp;550 authentication required > === > Just to be sure, have you checked the error code you are receiving against the list at https://blu002.mail.live.com/mail/troubleshooting.aspx#Codes and, if you are following the policy on that page and have a correctly configured server, filled in the postmaster contact form at https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts ? As the site says "If automation can determine [the IP range] to be eligible, the IPs may be mitigated. If not, the response will provide information about the status of the IPs and a link to report this to our Deliverability Support Staff who can than further investigate your issue. This team is available 24 x 7." Alex From "scoobydooxp" at 64systems.com Thu Oct 25 03:34:31 2012 From: "scoobydooxp" at 64systems.com (Scooby) Date: Wed, 24 Oct 2012 22:34:31 -0500 Subject: XO ethernet over copper (EoC) - MTU Message-ID: We recently had an XO EoC install turned up and it seems to have an odd MTU. XO Support had no idea what I was talking about when I called to ask. Does anyone know what the proper MTU should be? Thanks in advance, Scooby From sliplever at gmail.com Thu Oct 25 11:52:05 2012 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 25 Oct 2012 07:52:05 -0400 Subject: End User Experience Message-ID: Hello All- I am a currently researching how network operators monitor and/or detect degradation of the "end user's" experience. I would really appreciate it if everyone could take a few minutes to fill out my survey. It's at * http://questionpro.com/t/AJVauZOb2F* * * Thank you all again. Dan From sliplever at gmail.com Thu Oct 25 12:25:26 2012 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 25 Oct 2012 08:25:26 -0400 Subject: End User Experience In-Reply-To: References: Message-ID: Hello All- I am a currently researching how network operators monitor and/or detect degradation of the "end user's" experience. I would really appreciate it if everyone could take a few minutes to fill out my survey. It's at http://questionpro.com/t/AJVauZOb2F Thank you all again. Dan From pete at cariden.com Thu Oct 25 12:40:19 2012 From: pete at cariden.com (Pete Crocker) Date: Thu, 25 Oct 2012 12:40:19 +0000 Subject: End User Experience In-Reply-To: References: Message-ID: <090E0551-D3C6-4C51-A763-4C19B247236E@cariden.com> By "research", do you mean fill in marketing information for some vendor, or will the results be published somewhere? That may help get a better response if the purpose of the research is shared. I'm curious as to the questions, such as "What are you willing to spend on monitoring and/or detecting your end user's experience annually?". Regards, -pete On Oct 25, 2012, at 1:25 PM, Dan Snyder wrote: > Hello All- > > > I am a currently researching how network operators monitor and/or > detect degradation of the "end user's" experience. I would really > appreciate it if everyone could take a few minutes to fill out my > survey. It's at http://questionpro.com/t/AJVauZOb2F > > > Thank you all again. > > Dan > From owen at delong.com Thu Oct 25 12:38:14 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 25 Oct 2012 05:38:14 -0700 Subject: End User Experience In-Reply-To: References: Message-ID: <4F9A9375-4AC1-46EA-9460-2081E7EB8494@delong.com> That isn't a survey, it's a sales lead qualification questionnaire thinly disguised as a survey. Inappropriate to NANOG, IMHO. Owen On Oct 25, 2012, at 4:52 AM, Dan Snyder wrote: > Hello All- > > > I am a currently researching how network operators monitor and/or detect > degradation of the "end user's" experience. I would really appreciate it if > everyone could take a few minutes to fill out my survey. It's at * > http://questionpro.com/t/AJVauZOb2F* > > * > * > > Thank you all again. > > Dan From deric.kwok2000 at gmail.com Thu Oct 25 12:54:44 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 25 Oct 2012 08:54:44 -0400 Subject: need help 40 G Message-ID: Hi all I would like to ask any free program/method can test 40G I tested it by ip erf program but it is not over 20G Thank you From frnkblk at iname.com Thu Oct 25 13:18:29 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 25 Oct 2012 08:18:29 -0500 Subject: www.ipv6.facebook.com not loading Message-ID: <000601cdb2b3$395208a0$abf619e0$@iname.com> Since Wednesday at 1:48 pm Central www.ipv6.facebook.com has not been loading (though it's pingable). Does anyone know if this has been formally deprecated? Frank From jeroen at unfix.org Thu Oct 25 13:25:09 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 25 Oct 2012 09:25:09 -0400 Subject: www.ipv6.facebook.com not loading) In-Reply-To: <000601cdb2b3$395208a0$abf619e0$@iname.com> References: <000601cdb2b3$395208a0$abf619e0$@iname.com> Message-ID: <50893DB5.1020802@unfix.org> On 2012-10-25 09:18, Frank Bulk wrote: > Since Wednesday at 1:48 pm Central www.ipv6.facebook.com has not been > loading (though it's pingable). Does anyone know if this has been formally > deprecated? I am getting NXDOMAIN for www.ipv6.facebook.com thus it likely is fully gone now: 8<----------------------------------------------------------------------------- $ dig @a.ns.facebook.com. www.ipv6.facebook.com any ; <<>> DiG 9.8.1-P1 <<>> @a.ns.facebook.com. www.ipv6.facebook.com any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14078 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ipv6.facebook.com. IN ANY ;; AUTHORITY SECTION: facebook.com. 120 IN SOA a.ns.facebook.com. dns.facebook.com. 2012102401 7200 1800 604800 120 ;; Query time: 82 msec ;; SERVER: 69.171.239.12#53(69.171.239.12) ;; WHEN: Thu Oct 25 15:20:49 2012 ;; MSG SIZE rcvd: 84 ----------------------------------------------------------------------------->8 www.facebook.com is nicely at 2a03:2880:2050:1f01:face:b00c:: (which is kinda scary as typically the lowest address is a subnet anycast address, but I guess they have just configured it as a /128 and then it is not an issue...) Greets, Jeroen From scott at doc.net.au Thu Oct 25 13:40:44 2012 From: scott at doc.net.au (Scott Howard) Date: Thu, 25 Oct 2012 06:40:44 -0700 Subject: www.ipv6.facebook.com not loading) In-Reply-To: <50893DB5.1020802@unfix.org> References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50893DB5.1020802@unfix.org> Message-ID: On Thu, Oct 25, 2012 at 6:25 AM, Jeroen Massar wrote: > I am getting NXDOMAIN for www.ipv6.facebook.com thus it likely is fully > gone now: > Same from here. www.facebook.com is nicely at 2a03:2880:2050:1f01:face:b00c:: (which is > kinda scary as typically the lowest address is a subnet anycast address, > but I guess they have just configured it as a /128 and then it is not an > issue...) > The lowest address on that subnet (presuming a /64) would be 2a03:2880:2050:1f01:: Scott From rdobbins at arbor.net Thu Oct 25 13:45:21 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 25 Oct 2012 13:45:21 +0000 Subject: www.ipv6.facebook.com not loading) In-Reply-To: References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50893DB5.1020802@unfix.org> Message-ID: On Oct 25, 2012, at 8:40 PM, Scott Howard wrote: > Same from here. dig AAAA www.facebook.com. ; <<>> DiG 9.7.3-P3 <<>> AAAA www.facebook.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41039 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 49 IN CNAME www.c10r.facebook.com. www.c10r.facebook.com. 39 IN AAAA 2a03:2880:2110:9f01:face:b00c:: ;; AUTHORITY SECTION: c10r.facebook.com. 109916 IN NS b.ns.c10r.facebook.com. c10r.facebook.com. 109916 IN NS a.ns.c10r.facebook.com. ;; ADDITIONAL SECTION: a.ns.c10r.facebook.com. 111245 IN A 69.171.239.11 b.ns.c10r.facebook.com. 111539 IN A 69.171.255.11 ;; Query time: 11 msec ;; SERVER: 10.50.0.1#53(10.50.0.1) ;; WHEN: Thu Oct 25 20:44:10 2012 ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From sliplever at gmail.com Thu Oct 25 13:45:01 2012 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 25 Oct 2012 09:45:01 -0400 Subject: End User Experience In-Reply-To: <090E0551-D3C6-4C51-A763-4C19B247236E@cariden.com> References: <090E0551-D3C6-4C51-A763-4C19B247236E@cariden.com> Message-ID: I will publish the results of the survey. The questions on demographics and budget, are there to see if monitoring end user experience effectively is only available to companies who spend a fortune on tools. Thanks, Dan On Thu, Oct 25, 2012 at 8:40 AM, Pete Crocker wrote: > By "research", do you mean fill in marketing information for some vendor, or will the results be published somewhere? That may help get a better response if the purpose of the research is shared. > > I'm curious as to the questions, such as "What are you willing to spend on monitoring and/or detecting your end user's experience annually?". > > Regards, > -pete > > > On Oct 25, 2012, at 1:25 PM, Dan Snyder wrote: > >> Hello All- >> >> >> I am a currently researching how network operators monitor and/or >> detect degradation of the "end user's" experience. I would really >> appreciate it if everyone could take a few minutes to fill out my >> survey. It's at http://questionpro.com/t/AJVauZOb2F >> >> >> Thank you all again. >> >> Dan >> > From sliplever at gmail.com Thu Oct 25 13:46:16 2012 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 25 Oct 2012 09:46:16 -0400 Subject: End User Experience In-Reply-To: <4F9A9375-4AC1-46EA-9460-2081E7EB8494@delong.com> References: <4F9A9375-4AC1-46EA-9460-2081E7EB8494@delong.com> Message-ID: I am not asking for sales leads...they survey does not ask for you to identify yourself. On Thu, Oct 25, 2012 at 8:38 AM, Owen DeLong wrote: > That isn't a survey, it's a sales lead qualification questionnaire thinly disguised > as a survey. > > Inappropriate to NANOG, IMHO. > > Owen > > On Oct 25, 2012, at 4:52 AM, Dan Snyder wrote: > >> Hello All- >> >> >> I am a currently researching how network operators monitor and/or detect >> degradation of the "end user's" experience. I would really appreciate it if >> everyone could take a few minutes to fill out my survey. It's at * >> http://questionpro.com/t/AJVauZOb2F* >> >> * >> * >> >> Thank you all again. >> >> Dan > From jeroen at unfix.org Thu Oct 25 13:50:04 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 25 Oct 2012 09:50:04 -0400 Subject: www.ipv6.facebook.com not loading) In-Reply-To: References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50893DB5.1020802@unfix.org> Message-ID: <5089438C.6000500@unfix.org> On 2012-10-25 09:45, Dobbins, Roland wrote: [..] > ;; ANSWER SECTION: > www.facebook.com. 49 IN CNAME www.c10r.facebook.com. > www.c10r.facebook.com. 39 IN AAAA 2a03:2880:2110:9f01:face:b00c:: Interresting, I was just now getting responses pointing www.facebook.com to (long live infinite scrollback): 8<------------------------------------------------------------------- ;; AUTHORITY SECTION: www.facebook.com. 1800 IN NS glb2.facebook.com. www.facebook.com. 1800 IN NS glb1.facebook.com. ;; ADDITIONAL SECTION: glb1.facebook.com. 3600 IN A 69.171.239.10 glb2.facebook.com. 3600 IN A 69.171.255.10 ------------------------------------------------------------------->8 and then finally: www.facebook.com. 120 IN AAAA 2a03:2880:2050:1f01:face:b00c:: Note that is 2110 != 2050. But now indeed to the c10r one... thus there are at least a couple of clusters it seems. Greets, Jeroen From rdobbins at arbor.net Thu Oct 25 13:53:07 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 25 Oct 2012 13:53:07 +0000 Subject: www.ipv6.facebook.com not loading) In-Reply-To: <5089438C.6000500@unfix.org> References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50893DB5.1020802@unfix.org> <5089438C.6000500@unfix.org> Message-ID: <7937883B-3C7B-4E63-A2B8-55179DD429A7@arbor.net> On Oct 25, 2012, at 8:50 PM, Jeroen Massar wrote: > www.facebook.com. 120 IN AAAA 2a03:2880:2050:1f01:face:b00c:: I found this to be rather amusing. ;> > Note that is 2110 != 2050. Right. > But now indeed to the c10r one... thus there are at least a couple of clusters it seems I'm in ASEAN, FWIW. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nanog at jima.tk Thu Oct 25 14:17:52 2012 From: nanog at jima.tk (Jima) Date: Thu, 25 Oct 2012 08:17:52 -0600 (MDT) Subject: www.ipv6.facebook.com not loading In-Reply-To: <000601cdb2b3$395208a0$abf619e0$@iname.com> References: <000601cdb2b3$395208a0$abf619e0$@iname.com> Message-ID: <36276.2001:49f0:a057:0:905f:b10e:f647:59c.1351174672.squirrel@laughton.us> On 2012-10-25 07:18, Frank Bulk wrote: > Since Wednesday at 1:48 pm Central www.ipv6.facebook.com has not been > loading (though it's pingable). Does anyone know if this has been > formally > deprecated? As I recall, the primary IPv6-only FQDN was (and still is) www.v6.facebook.com . I honestly never noticed that they added an AAAA for www.ipv6.facebook.com . Hardly scientific, but http://www.googlefight.com/index.php?lang=en_GB&word1=www.v6.facebook.com&word2=www.ipv6.facebook.com seems to support my memory to some degree. Jima From nanog at null-routed.net Thu Oct 25 14:36:43 2012 From: nanog at null-routed.net (Will Lawton) Date: Thu, 25 Oct 2012 09:36:43 -0500 Subject: www.ipv6.facebook.com not loading In-Reply-To: <50894a26.86022b0a.6d62.553cSMTPIN_ADDED@mx.google.com> References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50894a26.86022b0a.6d62.553cSMTPIN_ADDED@mx.google.com> Message-ID: www.v6.facebook.com was the official pre-www AAAA record host. I recall a www.ipv6.facebook being added as a redirect because there seemed to be confusion around which one it was. Regardless, to answer the original question, yes www.v6.facebook.com has been official deprecated for almost 2 years now as it was only meant as a test platform for the inevitable www.facebook.com AAAA. If you can not get to www.facebook on v6, please work with your ISP to find out why. When I left there, it was still a whitelisting design for known good networks, but I believe that was done away with after this years ipv6 day. -Will Lawton On Oct 25, 2012, at 9:17, "Jima" wrote: > On 2012-10-25 07:18, Frank Bulk wrote: >> Since Wednesday at 1:48 pm Central www.ipv6.facebook.com has not been >> loading (though it's pingable). Does anyone know if this has been >> formally >> deprecated? > > As I recall, the primary IPv6-only FQDN was (and still is) > www.v6.facebook.com . I honestly never noticed that they added an AAAA > for www.ipv6.facebook.com . > > Hardly scientific, but > http://www.googlefight.com/index.php?lang=en_GB&word1=www.v6.facebook.com&word2=www.ipv6.facebook.com > seems to support my memory to some degree. > > Jima > > From donn.lists at gmail.com Thu Oct 25 21:08:00 2012 From: donn.lists at gmail.com (Donn Lee) Date: Thu, 25 Oct 2012 14:08:00 -0700 Subject: www.ipv6.facebook.com not loading In-Reply-To: References: <000601cdb2b3$395208a0$abf619e0$@iname.com> <50894a26.86022b0a.6d62.553cSMTPIN_ADDED@mx.google.com> Message-ID: Yes, www.v6.facebook.com has been deprecated. The dual-stacked www.facebook.com (via World IPv6 Launch) is the way to go, until we run out of addresses again. Thanks and cheers Donn ---------- Forwarded message ---------- > From: *Will Lawton* > Date: Thursday, October 25, 2012 > Subject: www.ipv6.facebook.com not loading > To: Jima > Cc: "nanog at nanog.org" > > > www.v6.facebook.com was the official pre-www AAAA record host. I recall a > www.ipv6.facebook being added as a redirect because there seemed to be > confusion around which one it was. > > Regardless, to answer the original question, yes www.v6.facebook.com has > been official deprecated for almost 2 years now as it was only meant as a > test platform for the inevitable www.facebook.com AAAA. > > If you can not get to www.facebook on v6, please work with your ISP to > find out why. When I left there, it was still a whitelisting design for > known good networks, but I believe that was done away with after this years > ipv6 day. > > -Will Lawton > > On Oct 25, 2012, at 9:17, "Jima" wrote: > > > On 2012-10-25 07:18, Frank Bulk wrote: > >> Since Wednesday at 1:48 pm Central www.ipv6.facebook.com has not been > >> loading (though it's pingable). Does anyone know if this has been > >> formally > >> deprecated? > > > > As I recall, the primary IPv6-only FQDN was (and still is) > > www.v6.facebook.com . I honestly never noticed that they added an AAAA > > for www.ipv6.facebook.com . > > > > Hardly scientific, but > > > http://www.googlefight.com/index.php?lang=en_GB&word1=www.v6.facebook.com&word2=www.ipv6.facebook.com > > seems to support my memory to some degree. > > > > Jima > > > > > > From jfmezei_nanog at vaxination.ca Fri Oct 26 08:12:49 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 26 Oct 2012 04:12:49 -0400 Subject: Wholesale FTTH implementation Message-ID: <508A4601.5090004@vaxination.ca> In Canada, there is an emerging wholesale ISP model where the regulator (CRTC) forces incumbents to make their last mile available for competitive retail services. This regulatory regime does not YET include FTTH last mile. To this end, I have some questions about FTTH deployments. Any answer to any of the topics is appreciated as it will give me better understanding of some of the technical aspects. *** Wavelengths (ok, this is a newbie question :-) It was my understanding that lasers were on/off devices which transmitted bits very fast. But I suspect I am very wrong on this because this doesnt seem to support RFoG deployment by cable, nor the Verizon FIOS which allocates some spectrum to TV and some to data. Anyone have a good pointer on how the lasers in an FTTH/GPON function ? Are they able to produce a wide range of "colours" and modulate signals ? Or are they really a bitstream with a single narrow colour and it is the hardware at both ends which converts between multi frequency broadcast signals and light pulses ? *** ONT Selection Are there standards similar to DOCSIS where in theory, any ONT *should* work on any GPON system ? (with carriers only qualifying a limited number of models on their system). Or does the selection of the OLT and line cards determine a narrow set of ONTs that are compatible ? Or does it get down to each carrier getting custom made ONTs for the system they are deploying ? Do most ONTs on the market generally allow end user access to some of the config/status data to help in debugging problems ? or are they generally inaccessible by users ? In the case of Bell Canada, I have obtained the following 2 images: http://www.vaxination.ca/temp/ont1.jpg outside equipment http://www.vaxination.ca/temp/ont2.jpg indoors equipment The ONT appears to be the alcatel-lucent equipment indoors. Would this mean that the outdoor equipment really acts only as a demarc which would be just a passive optical connector to join the patch cord to indoors CPE with the optical cable coming from the telephone pole ? >From what I have seen, Verizon FIOS uses an "all-in-1" ONT that is outdoors and provides ethernet, POTS phone and coax for TV services. So each carrier appears to have different approaches. (and Verizon also has spectrum dedicated to TV, spectrum to data and some to voice, which looks like a hybrid RFoG system). *** IPTV and packet priority/QoS/rate-limit In the case of Bell Canada, they have an IPTV service and they use twin PPPoE sessions on twin VLANs. One is the data connection to/from the BRAS, and the other is the IPTV stream from the Mediaroom data centre. (in the second picture, this would be handled by the black equipment on the left which would be the router that does the PPPoE sessions and outputs ethernet data and MoCA) In their VDSL2 environment, the DSLAM enforces QoS to give IPTV packets priority, reducing data througput to ensure it fits within the limited copper speeds. In an FTTH system, how would this be accomplished ? Would QoS and rate limiting be done by the ONT (since it is the new choke point where subscription speed is imposed), or would the OLT rate limit each end user's total bandwidth and prioritise IPTV packets to ensure it all fits whn it gets to the ONT's rate-limit ? Based on what I heard, those on Bell's FTTH have their IPTV streams fit within their subscription speed, so if they only subscribe to 16mbps service, and use 7mbps for IPTV, they only have 9mbps left for data. *** POTS Service >From a POTS service point of view, is it easy to specify that customer X's SIP traffic goes to server A, while customer Y's traffic goes to server B ? (aka: allow CLECs to provide VoIP service to end users) Does the ONT get the SIP server destination when it is provisioned or does it talk to the OLT and it is the OLT which routes voice traffic to the SIP server assigned to that customer ? **** Installation costs If a carrier has been installing FTTH systems for about 2 years now, would its installation costs have become fairly stable by now, or would they still be going down as the carrier optimises its processes and has more trained crews ? How long does it generally take before they have stable installation costs ? >From the information I have gathered, Bell uses Corning Flexnap on the telephone poles to connect lines to individual homes. Those are custom made at the factory for each street block (based on distances where each line to home will be). Is this fairly common method ? Or is it considered a more expensive method used by carriers with fewer trained employees ? If a carrier is using Flexnap to save on cable termination/connection manhours, would they also order pre-cut fibre cable runs between the flexnap on the telephone pole and each home ? Or would those be cut and terminated on the field ? And out of curiosity, in a Flexnap setup, what happens if a couple of fibre strands between two poles are damaged by a squirrel ? Does this mean that they have to manually splice the lines from the affected homes into spare strands on the cable ? I appreciate any guidance/information you may provide. The more information I can provide to the regulator, the more informed a debate there can be and thus a better regulatory decision. Jean-Fran?ois Mezei Vaxination Informatique Montr?al, Canada From khelms at ispalliance.net Fri Oct 26 17:10:49 2012 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 26 Oct 2012 13:10:49 -0400 Subject: Wholesale FTTH implementation In-Reply-To: <508A4601.5090004@vaxination.ca> References: <508A4601.5090004@vaxination.ca> Message-ID: <508AC419.2070004@ispalliance.net> On 10/26/2012 4:12 AM, Jean-Francois Mezei wrote: > *** Wavelengths (ok, this is a newbie question :-) > > It was my understanding that lasers were on/off devices which > transmitted bits very fast. But I suspect I am very wrong on this > because this doesnt seem to support RFoG deployment by cable, nor the > Verizon FIOS which allocates some spectrum to TV and some to data. > > Anyone have a good pointer on how the lasers in an FTTH/GPON function ? > Are they able to produce a wide range of "colours" and modulate signals > ? Or are they really a bitstream with a single narrow colour and it is > the hardware at both ends which converts between multi frequency > broadcast signals and light pulses ? Ok, the first thing to understand is that there are a lot of FTTH technologies and they really work very differently from each other. I'll describe three of the more common ones, but these are far from the only FTTH technologies. RFoG (RF over Glass) is simply taking the DOCSIS HFC network to the extreme where each home has its own fiber node in the nid. In this case there are generally only two wavelengths active on the glass, one for the upstream side and one for the down stream. Inside of those wavelengths things are further sub-divided into 6 Mhz (8 for EuroDOCSIS) wide channels on the downstream and 6.4 Mhz on the upstream. (3.2 if you're running modems older than DOCSIS 2.0). You can run RFoG as an overlay on an existing GPON installation and in that case the DOCSIS signalling is encapsulated inside of the PON layer 1 and layer 2 transmissions, but in my experience this is relatively uncommon. http://en.wikipedia.org/wiki/RFoG GPON (Gigabit Passive Optical Networking) is a technology that allows for multiple wavelengths to be sent down a strand (16/32/64) which is then split by a passive prism (no power or brains) to serve the households attached to that splitter. This is a pure data delivery mechanism so in many cases TV line ups are done as IP streams, however you can work with specific vendors to have the TV channels delivered separately in a normal MPEG2/4 stream that "normal" digital set top boxes can handle once its been converted to RF in the home. (This is the approach that Verizon took). Its also common to keep some amount of copper in the loop and instead of running fiber all the way to the home its run to a cabinet in a neighborhood and from there VDSL2 (with vectoring if possible) is the local distribution loop. This gets rid of the need for batteries in customer's homes and doesn't create a big drop in speed. This can only be done within about 4000 feet of the cabinet. http://en.wikipedia.org/wiki/Gpon Active Ethernet is yet another way of delivering services over a fiber plant and it requires the least amount explanation since it really works very similar to how ethernet works in normal enterprise networks and its a baseband technology. Having said that it can (and often is) combined with either course or dense WDM (Wave Division Multiplexing) to help keep the fiber count down and that does use multiple wavelengths. http://en.wikipedia.org/wiki/CWDM > > > > > *** ONT Selection > > Are there standards similar to DOCSIS where in theory, any ONT *should* > work on any GPON system ? (with carriers only qualifying a limited > number of models on their system). Or does the selection of the OLT and > line cards determine a narrow set of ONTs that are compatible ? > > Or does it get down to each carrier getting custom made ONTs for the > system they are deploying ? In general you find out from your OLT vendor what ONTs they work with other than their own. If you're in an open network scenario you'll have to get this from the infrastructure owner. > > > Do most ONTs on the market generally allow end user access to some of > the config/status data to help in debugging problems ? or are they > generally inaccessible by users ? They seldom if ever allow end user access. You should find out exactly what technology is being used, since some have decent stat reporting (DPoE) via SNMP while others use TR-069. > > > In the case of Bell Canada, I have obtained the following 2 images: > > http://www.vaxination.ca/temp/ont1.jpg outside equipment > http://www.vaxination.ca/temp/ont2.jpg indoors equipment > > The ONT appears to be the alcatel-lucent equipment indoors. Would this > mean that the outdoor equipment really acts only as a demarc which would > be just a passive optical connector to join the patch cord to indoors > CPE with the optical cable coming from the telephone pole ? You'll have to get the details on this from the infrastructure owner, there are tons of options for operators to choose from on indoor versus outdoor using the same technology. > > > >From what I have seen, Verizon FIOS uses an "all-in-1" ONT that is > outdoors and provides ethernet, POTS phone and coax for TV services. So > each carrier appears to have different approaches. (and Verizon also has > spectrum dedicated to TV, spectrum to data and some to voice, which > looks like a hybrid RFoG system). > > > *** IPTV and packet priority/QoS/rate-limit > > In the case of Bell Canada, they have an IPTV service and they use twin > PPPoE sessions on twin VLANs. One is the data connection to/from the > BRAS, and the other is the IPTV stream from the Mediaroom data centre. > (in the second picture, this would be handled by the black equipment on > the left which would be the router that does the PPPoE sessions and > outputs ethernet data and MoCA) > > In their VDSL2 environment, the DSLAM enforces QoS to give IPTV packets > priority, reducing data througput to ensure it fits within the limited > copper speeds. > > In an FTTH system, how would this be accomplished ? Would QoS and rate > limiting be done by the ONT (since it is the new choke point where > subscription speed is imposed), or would the OLT rate limit each end > user's total bandwidth and prioritise IPTV packets to ensure it all fits > whn it gets to the ONT's rate-limit ? > > Based on what I heard, those on Bell's FTTH have their IPTV streams fit > within their subscription speed, so if they only subscribe to 16mbps > service, and use 7mbps for IPTV, they only have 9mbps left for data. It _CAN_ be done by the ONT/OLT together, but that's a configuration/deployment choice. > > > > *** POTS Service > > >From a POTS service point of view, is it easy to specify that customer > X's SIP traffic goes to server A, while customer Y's traffic goes to > server B ? (aka: allow CLECs to provide VoIP service to end users) > > Does the ONT get the SIP server destination when it is provisioned or > does it talk to the OLT and it is the OLT which routes voice traffic to > the SIP server assigned to that customer ? Again, this one just depends on how the underlying carrier built it. Having said that if its not prioritized SIP traffic (unless the operator prioritizes all RTS data) it will simply be IP traffic that will go to where ever the SIP endpoint (phone, ATA, etc) is programmed to send it. If that route crosses the Internet WAN connection it can have QoS issues. > > > **** Installation costs > > If a carrier has been installing FTTH systems for about 2 years now, > would its installation costs have become fairly stable by now, or would > they still be going down as the carrier optimises its processes and has > more trained crews ? How long does it generally take before they have > stable installation costs ? It goes down some past the first two years but generally the biggest drop is during the first 12-16 months and those are process and crew experience related while the costs that drop after that tend to be driven by CPE costs dropping. > > >From the information I have gathered, Bell uses Corning Flexnap on the > telephone poles to connect lines to individual homes. Those are custom > made at the factory for each street block (based on distances where each > line to home will be). Is this fairly common method ? Or is it > considered a more expensive method used by carriers with fewer trained > employees ? > > If a carrier is using Flexnap to save on cable termination/connection > manhours, would they also order pre-cut fibre cable runs between the > flexnap on the telephone pole and each home ? Or would those be cut and > terminated on the field ? > > And out of curiosity, in a Flexnap setup, what happens if a couple of > fibre strands between two poles are damaged by a squirrel ? Does this > mean that they have to manually splice the lines from the affected homes > into spare strands on the cable ? I don't know enough about Flexnap to comment. > > > I appreciate any guidance/information you may provide. The more > information I can provide to the regulator, the more informed a debate > there can be and thus a better regulatory decision. > > > Jean-Fran?ois Mezei > Vaxination Informatique > Montr?al, Canada > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From cscora at apnic.net Fri Oct 26 18:50:52 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Oct 2012 04:50:52 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201210261850.q9QIoq3N022118@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 27 Oct, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 429634 Prefixes after maximum aggregation: 179531 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 211158 Total ASes present in the Internet Routing Table: 42474 Prefixes per ASN: 10.12 Origin-only ASes present in the Internet Routing Table: 33773 Origin ASes announcing only one prefix: 15820 Transit ASes present in the Internet Routing Table: 5659 Transit-only ASes present in the Internet Routing Table: 145 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 871 Unregistered ASNs in the Routing Table: 322 Number of 32-bit ASNs allocated by the RIRs: 3412 Number of 32-bit ASNs visible in the Routing Table: 3042 Prefixes from 32-bit ASNs in the Routing Table: 8244 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 159 Number of addresses announced to Internet: 2608859500 Equivalent to 155 /8s, 128 /16s and 9 /24s Percentage of available address space announced: 70.5 Percentage of allocated address space announced: 70.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.8 Total number of prefixes smaller than registry allocations: 150954 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 103698 Total APNIC prefixes after maximum aggregation: 32582 APNIC Deaggregation factor: 3.18 Prefixes being announced from the APNIC address blocks: 104472 Unique aggregates announced from the APNIC address blocks: 42967 APNIC Region origin ASes present in the Internet Routing Table: 4783 APNIC Prefixes per ASN: 21.84 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 779 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 340 Number of APNIC addresses announced to Internet: 712220960 Equivalent to 42 /8s, 115 /16s and 161 /24s Percentage of available APNIC address space announced: 83.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 154902 Total ARIN prefixes after maximum aggregation: 78361 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155759 Unique aggregates announced from the ARIN address blocks: 69605 ARIN Region origin ASes present in the Internet Routing Table: 15296 ARIN Prefixes per ASN: 10.18 ARIN Region origin ASes announcing only one prefix: 5788 ARIN Region transit ASes present in the Internet Routing Table: 1600 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087370112 Equivalent to 64 /8s, 207 /16s and 243 /24s Percentage of available ARIN address space announced: 57.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 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: 108872 Total RIPE prefixes after maximum aggregation: 57549 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 111543 Unique aggregates announced from the RIPE address blocks: 72153 RIPE Region origin ASes present in the Internet Routing Table: 16922 RIPE Prefixes per ASN: 6.59 RIPE Region origin ASes announcing only one prefix: 8139 RIPE Region transit ASes present in the Internet Routing Table: 2750 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1984 Number of RIPE addresses announced to Internet: 648338212 Equivalent to 38 /8s, 164 /16s and 219 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44124 Total LACNIC prefixes after maximum aggregation: 8743 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 47539 Unique aggregates announced from the LACNIC address blocks: 22817 LACNIC Region origin ASes present in the Internet Routing Table: 1686 LACNIC Prefixes per ASN: 28.20 LACNIC Region origin ASes announcing only one prefix: 471 LACNIC Region transit ASes present in the Internet Routing Table: 315 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 696 Number of LACNIC addresses announced to Internet: 118264488 Equivalent to 7 /8s, 12 /16s and 146 /24s Percentage of available LACNIC address space announced: 70.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9678 Total AfriNIC prefixes after maximum aggregation: 2242 AfriNIC Deaggregation factor: 4.32 Prefixes being announced from the AfriNIC address blocks: 10162 Unique aggregates announced from the AfriNIC address blocks: 3476 AfriNIC Region origin ASes present in the Internet Routing Table: 567 AfriNIC Prefixes per ASN: 17.92 AfriNIC Region origin ASes announcing only one prefix: 173 AfriNIC Region transit ASes present in the Internet Routing Table: 124 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 42372864 Equivalent to 2 /8s, 134 /16s and 143 /24s Percentage of available AfriNIC address space announced: 42.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 2972 11558 900 Korea Telecom (KIX) 17974 2418 829 55 PT TELEKOMUNIKASI INDONESIA 7545 1785 301 86 TPG Internet Pty Ltd 4755 1610 375 158 TATA Communications formerly 9829 1398 1152 36 BSNL National Internet Backbo 9583 1187 88 509 Sify Limited 4808 1112 2056 314 CNCGROUP IP network: China169 7552 1105 1062 11 Vietel Corporation 24560 1035 385 162 Bharti Airtel Ltd., Telemedia 9498 1027 310 74 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 3178 3724 164 bellsouth.net, inc. 7029 3132 989 161 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1928 678 126 PaeTec Communications, Inc. 22773 1909 2931 128 Cox Communications, Inc. 20115 1665 1586 617 Charter Communications 4323 1592 1155 393 Time Warner Telecom 30036 1373 274 726 Mediacom Communications Corp 7018 1276 10290 849 AT&T WorldNet Services 7011 1222 334 692 Citizens Utilities 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 8402 1847 544 16 Corbina telecom 12479 853 776 64 Uni2 Autonomous System 34984 822 207 198 BILISIM TELEKOM 31148 726 37 9 FreeNet ISP 6830 724 2314 446 UPC Distribution Services 13188 707 93 134 Educational Network 20940 699 223 548 Akamai Technologies European 2118 664 97 14 EUnet/RELCOM Autonomous Syste 58113 601 66 364 LIR DATACENTER TELECOM SRL 8551 595 364 61 Bezeq International 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 2224 378 227 TVCABLE BOGOTA 28573 2138 1276 77 NET Servicos de Comunicao S.A 7303 1661 1131 201 Telecom Argentina Stet-France 8151 1590 3030 356 UniNet S.A. de C.V. 6503 1524 435 68 AVANTEL, S.A. 27947 739 74 96 Telconet S.A 3816 652 309 69 Empresa Nacional de Telecomun 14420 593 89 103 CORPORACION NACIONAL DE TELEC 11172 589 85 65 Servicios Alestra S.A de C.V 7738 585 1178 33 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 899 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 651 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 287 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 172 697 88 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3178 3724 164 bellsouth.net, inc. 7029 3132 989 161 Windstream Communications Inc 4766 2972 11558 900 Korea Telecom (KIX) 17974 2418 829 55 PT TELEKOMUNIKASI INDONESIA 10620 2224 378 227 TVCABLE BOGOTA 28573 2138 1276 77 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1928 678 126 PaeTec Communications, Inc. 22773 1909 2931 128 Cox Communications, Inc. 8402 1847 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3132 2971 Windstream Communications Inc 17974 2418 2363 PT TELEKOMUNIKASI INDONESIA 4766 2972 2072 Korea Telecom (KIX) 28573 2138 2061 NET Servicos de Comunicao S.A 10620 2224 1997 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 8402 1847 1831 Corbina telecom 1785 1928 1802 PaeTec Communications, Inc. 22773 1909 1781 Cox Communications, Inc. 7545 1785 1699 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 61408 UNALLOCATED 5.56.0.0/22 174 Cogent Communication 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:87 /12:241 /13:478 /14:850 /15:1549 /16:12459 /17:6510 /18:10856 /19:21231 /20:30542 /21:32534 /22:43081 /23:40258 /24:224641 /25:1358 /26:1692 /27:907 /28:180 /29:77 /30:17 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2622 3132 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1791 3178 bellsouth.net, inc. 8402 1549 1847 Corbina telecom 30036 1294 1373 Mediacom Communications Corp 22773 1249 1909 Cox Communications, Inc. 11492 1149 1184 Cable One 6503 1054 1524 AVANTEL, S.A. 1785 1018 1928 PaeTec Communications, Inc. 7011 957 1222 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:645 2:785 3:1 4:13 5:581 6:3 8:478 12:1979 13:3 14:681 15:11 16:3 17:6 20:27 23:207 24:1787 27:1370 31:1030 32:54 33:2 34:2 36:7 37:917 38:835 39:2 40:136 41:2788 42:175 44:3 46:1638 47:2 49:461 50:612 52:12 54:25 55:7 56:4 57:27 58:983 59:546 60:237 61:1301 62:972 63:2005 64:4282 65:2228 66:4531 67:2083 68:1159 69:3228 70:986 71:506 72:1882 74:2614 75:478 76:308 77:975 78:1009 79:506 80:1234 81:982 82:623 83:542 84:526 85:1153 86:485 87:942 88:360 89:1810 90:303 91:5281 92:588 93:1445 94:1676 95:1264 96:395 97:325 98:967 99:39 100:30 101:292 103:1702 105:512 106:122 107:201 108:473 109:1612 110:810 111:977 112:436 113:734 114:632 115:869 116:888 117:758 118:948 119:1227 120:360 121:693 122:1694 123:1161 124:1339 125:1284 128:574 129:197 130:284 131:645 132:309 133:142 134:252 135:62 136:220 137:238 138:337 139:170 140:492 141:289 142:491 143:377 144:494 145:82 146:517 147:267 148:727 149:330 150:158 151:204 152:450 153:182 154:21 155:436 156:227 157:371 158:286 159:664 160:337 161:414 162:365 163:191 164:710 165:449 166:512 167:560 168:998 169:126 170:908 171:152 172:7 173:1702 174:611 175:452 176:779 177:1342 178:1619 180:1357 181:162 182:1108 183:314 184:610 185:42 186:2210 187:1374 188:1707 189:1598 190:5892 192:6040 193:5546 194:4275 195:3459 196:1234 197:248 198:3911 199:5083 200:6009 201:1962 202:8709 203:8720 204:4412 205:2521 206:2745 207:2805 208:4056 209:3626 210:2833 211:1536 212:2073 213:1830 214:884 215:87 216:5131 217:1559 218:572 219:307 220:1257 221:533 222:338 223:405 End of report From cidr-report at potaroo.net Fri Oct 26 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Oct 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201210262200.q9QM00lH005058@wattle.apnic.net> This report has been generated at Fri Oct 26 21:13:08 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-10-12 430920 249732 20-10-12 431344 250026 21-10-12 431451 250000 22-10-12 431460 249854 23-10-12 431604 250233 24-10-12 431759 250199 25-10-12 431612 249929 26-10-12 431572 249346 AS Summary 42590 Number of ASes in routing system 17742 Number of ASes announcing only one prefix 3178 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 114099168 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 26Oct12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 432154 249257 182897 42.3% All ASes AS6389 3178 168 3010 94.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2149 62 2087 97.1% NET Servicos de Comunicao S.A. AS4766 2977 941 2036 68.4% KIXS-AS-KR Korea Telecom AS7029 3133 1345 1788 57.1% WINDSTREAM - Windstream Communications Inc AS17974 2418 635 1783 73.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1909 132 1777 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS7303 1661 425 1236 74.4% Telecom Argentina S.A. AS4323 1598 401 1197 74.9% TWTC - tw telecom holdings, inc. AS4755 1610 525 1085 67.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 2224 1278 946 42.5% Telmex Colombia S.A. AS7545 1785 855 930 52.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS7552 1105 201 904 81.8% VIETEL-AS-AP Vietel Corporation AS8151 1598 704 894 55.9% Uninet S.A. de C.V. AS18101 1018 174 844 82.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1112 347 765 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 862 115 747 86.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS1785 1928 1229 699 36.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS855 702 53 649 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1107 484 623 56.3% LEVEL3 Level 3 Communications AS17676 709 87 622 87.7% GIGAINFRA Softbank BB Corp. AS3549 1035 439 596 57.6% GBLX Global Crossing Ltd. AS22561 1022 429 593 58.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1001 409 592 59.1% VZGNI-TRANSIT - Verizon Online LLC AS24560 1035 451 584 56.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS2118 664 88 576 86.7% RELCOM-AS OOO "NPO Relcom" AS36998 772 203 569 73.7% SDN-MOBITEL AS4780 843 291 552 65.5% SEEDNET Digital United Inc. AS22047 578 30 548 94.8% VTR BANDA ANCHA S.A. AS4804 638 97 541 84.8% MPX-AS Microplex PTY LTD Total 44455 13021 31434 70.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 65.111.16.0/20 AS26407 GUILFORD-COMMUNICATIONS - Guilford Communications, Inc. 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 26 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Oct 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201210262200.q9QM028r005077@wattle.apnic.net> BGP Update Report Interval: 18-Oct-12 -to- 25-Oct-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31560 101535 3.7% 1471.5 -- INSOURCE Insource LLC 2 - AS52107 60793 2.2% 1899.8 -- CPOINT-AS LLC "C Point" 3 - AS29076 47401 1.7% 1823.1 -- CITYTELECOM-AS Citytelecom.ru 4 - AS8402 46450 1.7% 21.7 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS28306 45608 1.7% 1303.1 -- TC Net Inform?tica e Telecomunica??es LTDA 6 - AS44436 34078 1.2% 921.0 -- EFFORTEL-AS LLC MyBox 7 - AS9829 27615 1.0% 19.6 -- BSNL-NIB National Internet Backbone 8 - AS22561 26122 0.9% 24.9 -- DIGITAL-TELEPORT - Digital Teleport Inc. 9 - AS24560 21975 0.8% 21.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - AS1637 20390 0.7% 229.1 -- DNIC-AS-01637 - Headquarters, USAISC 11 - AS38370 19073 0.7% 109.6 -- CRNET-GD CHINA RAILWAY Internet Guangdong Branch 12 - AS13118 17369 0.6% 354.5 -- ASN-YARTELECOM OJSC Rostelecom 13 - AS48366 17044 0.6% 1893.8 -- INFOROOM Inforoom Ltd. 14 - AS7029 16577 0.6% 5.1 -- WINDSTREAM - Windstream Communications Inc 15 - AS45069 15133 0.6% 122.0 -- CNNIC-CTTSDNET-AP china tietong Shandong net 16 - AS7552 15044 0.6% 13.3 -- VIETEL-AS-AP Vietel Corporation 17 - AS5800 14181 0.5% 56.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS6389 11899 0.4% 3.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS2708 11842 0.4% 86.4 -- Universidad de Guanajuato 20 - AS2697 11648 0.4% 56.3 -- ERX-ERNET-AS Education and Research Network TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21684 5769 0.2% 5769.0 -- CYBERINETBGP - Cyberonics, Inc. 2 - AS24057 5334 0.2% 5334.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS21271 2930 0.1% 2930.0 -- SOTELMABGP 4 - AS14680 7223 0.3% 2407.7 -- REALE-6 - Auction.com 5 - AS59706 4397 0.2% 2198.5 -- IBC-AS-TIRANA I.B.C shpk 6 - AS43307 1948 0.1% 1948.0 -- ALTLINUX-AS ALT Linux Technology 7 - AS29503 1929 0.1% 1929.0 -- RATMIR-MOSCOW-AS Ratmir KDS 8 - AS51522 1928 0.1% 1928.0 -- DJANKOIONLINE DjankoiOnline Ltd 9 - AS12608 3851 0.1% 1925.5 -- MAXHOSTING-AS MediaServicePlus Ltd. 10 - AS50548 1925 0.1% 1925.0 -- QWENET-AS Qwe.Net ISP 11 - AS57383 1924 0.1% 1924.0 -- ASTERRANET FLP Sidorenko Aleksandr Aleksandrovich 12 - AS49124 3835 0.1% 1917.5 -- CENTROSET-AS CentroSet Ltd. 13 - AS42974 1915 0.1% 1915.0 -- NET-SBERBANK-AST CJSC Sberbank-AST 14 - AS47747 1911 0.1% 1911.0 -- TMK-NET-AS JSC "TMK-Telekom" 15 - AS42975 3816 0.1% 1908.0 -- FEOSKY-AS Foton-Service ISP 16 - AS57191 1906 0.1% 1906.0 -- CHUDOTELECOM-AS IT Business Ltd. 17 - AS3 1906 0.1% 1618.0 -- CMED-AS Cmed Technology Ltd 18 - AS51699 1900 0.1% 1900.0 -- ANTARKTIDA-PLUS-AS Antarktida-Plus LLC 19 - AS52107 60793 2.2% 1899.8 -- CPOINT-AS LLC "C Point" 20 - AS58049 1898 0.1% 1898.0 -- TECHSUPPORT-AS Telecom Tekhpodderzhka Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 17225 0.5% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 12792 0.4% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 182.64.0.0/16 10243 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 200.46.0.0/19 9872 0.3% AS21599 -- NETDIRECT S.A. 5 - 184.157.224.0/19 9854 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - 202.41.70.0/24 7880 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 7 - 122.161.0.0/16 7773 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 215.65.61.0/24 6911 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 9 - 187.94.82.0/24 5879 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 10 - 187.94.81.0/24 5878 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 11 - 189.38.10.0/24 5877 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 12 - 189.38.8.0/24 5876 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 13 - 189.38.15.0/24 5875 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 14 - 189.38.5.0/24 5875 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 15 - 12.139.133.0/24 5797 0.2% AS14680 -- REALE-6 - Auction.com 16 - 216.4.42.0/24 5769 0.2% AS21684 -- CYBERINETBGP - Cyberonics, Inc. 17 - 95.128.195.0/24 5466 0.2% AS39915 -- PREM-AS Premiere Global Services 18 - 202.14.255.0/24 5334 0.2% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 19 - 37.232.128.0/18 5254 0.2% AS12714 -- TI-AS Net By Net Holding LLC 20 - 192.58.232.0/24 5187 0.2% AS6629 -- NOAA-AS - NOAA 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 khomyakov.andrey at gmail.com Fri Oct 26 23:12:09 2012 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Fri, 26 Oct 2012 19:12:09 -0400 Subject: IOS architecture Message-ID: Does anyone know if there is an updated version of this book? Year 2000 seems so distant now... http://www.amazon.com/dp/B0051TM4RC/ref=rdr_kindle_ext_tmb --Andrey From david at davidswafford.com Sat Oct 27 00:01:58 2012 From: david at davidswafford.com (David Swafford) Date: Fri, 26 Oct 2012 20:01:58 -0400 Subject: IOS architecture In-Reply-To: References: Message-ID: I too have been wondering if this would ever get revived..... the only book on NX-OS software is so basic too :-( David. On Fri, Oct 26, 2012 at 7:12 PM, Andrey Khomyakov wrote: > Does anyone know if there is an updated version of this book? Year 2000 > seems so distant now... > > http://www.amazon.com/dp/B0051TM4RC/ref=rdr_kindle_ext_tmb > > --Andrey From blair.trosper at updraftnetworks.com Sat Oct 27 00:13:21 2012 From: blair.trosper at updraftnetworks.com (Blair Trosper) Date: Fri, 26 Oct 2012 19:13:21 -0500 Subject: Google PTR? Message-ID: I'm sure I'm bringing up a topic that's been brought up before, but I figured I'd have a go. Anyone from Google around that could answer to why there is no reverse DNS/PTR with most Google IP addresses (from traceroute, etc)? Alternatively, is there a server that can be utilized by the net operators community to at least get an answer on some of the IPs? It's very frustrating to contend with no PTR records in traces for troubleshooting and the like. Any information (off list or on) would be greatly appreciated. Thanks, Blair Trosper Updraft Networks & North Texas GigaPOP From tim at bobbroadband.com Sat Oct 27 01:02:55 2012 From: tim at bobbroadband.com (Tim Huffman) Date: Sat, 27 Oct 2012 01:02:55 +0000 Subject: DNS for ben.edu Message-ID: We are the primary DNS servers for the ben.edu domain. We seem to be having an issue with an AT&T server that is responding with incorrect A records for www.ben.edu and ben.edu. What it SHOULD be the response: nslookup www.ben.edu Server: 63.250.224.66 Address: 63.250.224.66#53 www.ben.edu canonical name = ben.edu. Name: ben.edu Address: 38.100.120.100 What 12.127.17.83 is responding with: > www.ben.edu Server: tbru.br.rs.els-gms.att.net Address: 12.127.17.83 Non-authoritative answer: Name: www.ben.edu Address: 208.91.197.132 This appears to be affecting only iPhones and iPads on the AT&T network. Is anybody else having problems with this? Are there any AT&T people on this list that can help? Tim Huffman Business Only Broadband 777 Oakmont Lane, Suite 2000, Westmont, IL 60559 Direct: 630.590.6012 | Main: 630.590.6000 | Fax: 630.986.2496 thuffman at bobbroadband.com | http://www.bobbroadband.com/ Cell: 630.340.1925 | Toll-Free Customer Support: 877.262.4553 [https://staticapp.icpsc.com/icp/loadimage.php/mogile/933825/747f0f3e66a4e0ce7633ff898bfc5121/image/png] Follow Us on LinkedIn | [https://files.icontact.com/templates/v2/CleanAndSimple/images/twitter.gif] Follow Us on Twitter P please consider the environment prior to printing -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2480 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1287 bytes Desc: image002.gif URL: From marka at isc.org Sat Oct 27 03:47:52 2012 From: marka at isc.org (Mark Andrews) Date: Sat, 27 Oct 2012 14:47:52 +1100 Subject: DNS for ben.edu In-Reply-To: Your message of "Sat, 27 Oct 2012 01:02:55 -0000." References: Message-ID: <20121027034752.3CDB42A55284@drugs.dv.isc.org> In message , Tim Huffman writes: > > We are the primary DNS servers for the ben.edu domain. We seem to be > having an issue with an AT&T server that is responding with incorrect A > records for www.ben.edu and ben.edu. > > What it SHOULD be the response: > nslookup www.ben.edu > Server: 63.250.224.66 > Address: 63.250.224.66#53 > > www.ben.edu canonical name = ben.edu. > Name: ben.edu > Address: 38.100.120.100 > > What 12.127.17.83 is responding with: > > www.ben.edu > Server: tbru.br.rs.els-gms.att.net > Address: 12.127.17.83 > > Non-authoritative answer: > Name: www.ben.edu > Address: 208.91.197.132 Looks to be right now. Did you wait a full day for the old records to timeout of the caches? ; <<>> DiG 9.10.0pre-alpha <<>> www.ben.edu @tbru.br.rs.els-gms.att.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8202 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.ben.edu. IN A ;; ANSWER SECTION: www.ben.edu. 86355 IN CNAME ben.edu. ben.edu. 86355 IN A 38.100.120.100 ;; Query time: 164 msec ;; SERVER: 12.127.17.83#53(12.127.17.83) ;; WHEN: Sat Oct 27 14:45:26 2012 ;; MSG SIZE rcvd: 70 > This appears to be affecting only iPhones and iPads on the AT&T network. > Is anybody else having problems with this? Are there any AT&T people on > this list that can help? > > > > Tim Huffman > Business Only Broadband > 777 Oakmont Lane, Suite 2000, Westmont, IL 60559 > Direct: 630.590.6012 | Main: 630.590.6000 | Fax: 630.986.2496 > thuffman at bobbroadband.com | > http://www.bobbroadband.com/ > Cell: 630.340.1925 | Toll-Free Customer Support: 877.262.4553 > [https://staticapp.icpsc.com/icp/loadimage.php/mogile/933825/747f0f3e66a4e > 0ce7633ff898bfc5121/image/png] Follow Us on > LinkedIn | > [https://files.icontact.com/templates/v2/CleanAndSimple/images/twitter.gif > ] Follow Us on Twitter > P please consider the environment prior to printing > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at afxr.net Sat Oct 27 03:52:18 2012 From: nanog at afxr.net (nanog) Date: Fri, 26 Oct 2012 22:52:18 -0500 Subject: Google PTR? In-Reply-To: References: Message-ID: <508B5A72.30904@afxr.net> On 10/26/2012 7:13 PM, Blair Trosper wrote: > I'm sure I'm bringing up a topic that's been brought up before, but I > figured I'd have a go. > > Anyone from Google around that could answer to why there is no reverse > DNS/PTR with most Google IP addresses (from traceroute, etc)? > > Alternatively, is there a server that can be utilized by the net operators > community to at least get an answer on some of the IPs? > > It's very frustrating to contend with no PTR records in traces for > troubleshooting and the like. > > Any information (off list or on) would be greatly appreciated. > > Thanks, > Blair Trosper > Updraft Networks & North Texas GigaPOP Which particular address are you referring to? I get PTR responses for the limited set of address I get from google. such as den03s06-in-x14.1e100.net [2607:f8b0:400f:801::1014] From drc at virtualized.org Sat Oct 27 05:24:50 2012 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Oct 2012 22:24:50 -0700 Subject: DNS for ben.edu In-Reply-To: <20121027034752.3CDB42A55284@drugs.dv.isc.org> References: <20121027034752.3CDB42A55284@drugs.dv.isc.org> Message-ID: Mark, On Oct 26, 2012, at 8:47 PM, Mark Andrews wrote: > Looks to be right now. Nope. Depends on from where you ask (presumably the AT&T resolvers are anycast). This is from a machine at LINX just now: % dig @12.127.17.83 www.ben.edu ; <<>> DiG 9.9.2-vjs287.12 <<>> @12.127.17.83 www.ben.edu ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58630 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.ben.edu. IN A ;; ANSWER SECTION: www.ben.edu. 300 IN A 208.91.197.132 ;; Query time: 142 msec ;; SERVER: 12.127.17.83#53(12.127.17.83) ;; WHEN: Sat Oct 27 06:21:06 2012 ;; MSG SIZE rcvd: 56 drc at shaun:~ % dig @12.127.17.83 www.ben.edu ns ; <<>> DiG 9.9.2-vjs287.12 <<>> @12.127.17.83 www.ben.edu ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15853 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.ben.edu. IN NS ;; ANSWER SECTION: www.ben.edu. 300 IN NS ns2432.ztomy.com. www.ben.edu. 300 IN NS ns1432.ztomy.com. ;; Query time: 134 msec ;; SERVER: 12.127.17.83#53(12.127.17.83) ;; WHEN: Sat Oct 27 06:21:14 2012 ;; MSG SIZE rcvd: 91 This is from a colo near Dallas: % dig @12.127.17.83 www.ben.edu ; <<>> DiG 9.7.7 <<>> @12.127.17.83 www.ben.edu ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61112 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ben.edu. IN A ;; ANSWER SECTION: www.ben.edu. 76133 IN CNAME ben.edu. ben.edu. 76133 IN A 38.100.120.100 ;; Query time: 2 msec ;; SERVER: 12.127.17.83#53(12.127.17.83) ;; WHEN: Sat Oct 27 05:22:51 2012 ;; MSG SIZE rcvd: 59 and this is from Comcast in the Bay Area: % dig @12.127.17.83 www.ben.edu ; <<>> DiG 9.9.0rc1 <<>> @12.127.17.83 www.ben.edu ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51363 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.ben.edu. IN A ;; ANSWER SECTION: www.ben.edu. 76097 IN CNAME ben.edu. ben.edu. 76097 IN A 38.100.120.100 ;; Query time: 110 msec ;; SERVER: 12.127.17.83#53(12.127.17.83) ;; WHEN: Fri Oct 26 22:23:46 2012 ;; MSG SIZE rcvd: 70 Regards, -drc From morrowc.lists at gmail.com Sat Oct 27 06:48:35 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 27 Oct 2012 02:48:35 -0400 Subject: Google PTR? In-Reply-To: <508B5A72.30904@afxr.net> References: <508B5A72.30904@afxr.net> Message-ID: On Fri, Oct 26, 2012 at 11:52 PM, nanog wrote: > On 10/26/2012 7:13 PM, Blair Trosper wrote: >> >> I'm sure I'm bringing up a topic that's been brought up before, but I >> figured I'd have a go. >> >> Anyone from Google around that could answer to why there is no reverse >> DNS/PTR with most Google IP addresses (from traceroute, etc)? >> >> Alternatively, is there a server that can be utilized by the net operators >> community to at least get an answer on some of the IPs? >> >> It's very frustrating to contend with no PTR records in traces for >> troubleshooting and the like. >> >> Any information (off list or on) would be greatly appreciated. >> >> Thanks, >> Blair Trosper >> Updraft Networks & North Texas GigaPOP > > Which particular address are you referring to? > I get PTR responses for the limited set of address I get from google. examples are good... I suspect he means things inside 15169's network that are not serving external people services: 209.85.243.114 for instance? From darrenoc at outlook.com Sat Oct 27 10:16:10 2012 From: darrenoc at outlook.com (Darren O'Connor) Date: Sat, 27 Oct 2012 11:16:10 +0100 Subject: IOS architecture In-Reply-To: References: , Message-ID: All vendors should be writing in depth architecture books. The Juniper MX book is a great example. Tell us exactly what your product can do and we'll likely use more of it > Date: Fri, 26 Oct 2012 20:01:58 -0400 > Subject: Re: IOS architecture > From: david at davidswafford.com > To: khomyakov.andrey at gmail.com > CC: nanog at nanog.org > > I too have been wondering if this would ever get revived..... the > only book on NX-OS software is so basic too :-( > > > David. > > On Fri, Oct 26, 2012 at 7:12 PM, Andrey Khomyakov > wrote: > > Does anyone know if there is an updated version of this book? Year 2000 > > seems so distant now... > > > > http://www.amazon.com/dp/B0051TM4RC/ref=rdr_kindle_ext_tmb > > > > --Andrey > From me at anuragbhatia.com Sat Oct 27 11:05:41 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 27 Oct 2012 16:35:41 +0530 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: Hi Blair I guess that's pretty much because they don't really wish to put any info related to routers in public including location & circuit bandwidth which is often given major networks in PTR. Btw I guess you must be troubleshooting some routing issue. My experience has been decent with them in past. They are usually responsive on the email addresses mentioned in peering db for AS15169. http://www.peeringdb.com/view.php?asn=15169 On Sat, Oct 27, 2012 at 12:18 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Fri, Oct 26, 2012 at 11:52 PM, nanog wrote: > > On 10/26/2012 7:13 PM, Blair Trosper wrote: > >> > >> I'm sure I'm bringing up a topic that's been brought up before, but I > >> figured I'd have a go. > >> > >> Anyone from Google around that could answer to why there is no reverse > >> DNS/PTR with most Google IP addresses (from traceroute, etc)? > >> > >> Alternatively, is there a server that can be utilized by the net > operators > >> community to at least get an answer on some of the IPs? > >> > >> It's very frustrating to contend with no PTR records in traces for > >> troubleshooting and the like. > >> > >> Any information (off list or on) would be greatly appreciated. > >> > >> Thanks, > >> Blair Trosper > >> Updraft Networks & North Texas GigaPOP > > > > Which particular address are you referring to? > > I get PTR responses for the limited set of address I get from google. > > examples are good... I suspect he means things inside 15169's network > that are not serving external people services: 209.85.243.114 > > for instance? > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From morrowc.lists at gmail.com Sat Oct 27 18:28:27 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 27 Oct 2012 14:28:27 -0400 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: On Sat, Oct 27, 2012 at 7:05 AM, Anurag Bhatia wrote: > Hi Blair > > > I guess that's pretty much because they don't really wish to put any info > related to routers in public including location & circuit bandwidth which is > often given major networks in PTR. > more over, what help is it? I'm of two minds really about this: 1) it's handy to say: the router in elbonia is being 'bad' 2) it's just as simple to say: 'your router with interface ip 1.2.3.4 is being bad' (or: "everything through 1.2.3.4 is forked... plstofixkthxbi!") It's often cited as a headache to maintain the PTRs (not really, automation ftw!) I think really it gets down to "how does it really help?" > Btw I guess you must be troubleshooting some routing issue. My experience > has been decent with them in past. They are usually responsive on the email > addresses mentioned in peering db for AS15169. also folk watch this list (and others)...though certainly the proper contact method is that which is in peeringdb. > http://www.peeringdb.com/view.php?asn=15169 > > > > > > On Sat, Oct 27, 2012 at 12:18 PM, Christopher Morrow > wrote: >> >> On Fri, Oct 26, 2012 at 11:52 PM, nanog wrote: >> > On 10/26/2012 7:13 PM, Blair Trosper wrote: >> >> >> >> I'm sure I'm bringing up a topic that's been brought up before, but I >> >> figured I'd have a go. >> >> >> >> Anyone from Google around that could answer to why there is no reverse >> >> DNS/PTR with most Google IP addresses (from traceroute, etc)? >> >> >> >> Alternatively, is there a server that can be utilized by the net >> >> operators >> >> community to at least get an answer on some of the IPs? >> >> >> >> It's very frustrating to contend with no PTR records in traces for >> >> troubleshooting and the like. >> >> >> >> Any information (off list or on) would be greatly appreciated. >> >> >> >> Thanks, >> >> Blair Trosper >> >> Updraft Networks & North Texas GigaPOP >> > >> > Which particular address are you referring to? >> > I get PTR responses for the limited set of address I get from google. >> >> examples are good... I suspect he means things inside 15169's network >> that are not serving external people services: 209.85.243.114 >> >> for instance? >> > > > > -- > > Anurag Bhatia > anuragbhatia.com > > Linkedin | Twitter | Google+ > > > From alumbis at gmail.com Sat Oct 27 21:00:46 2012 From: alumbis at gmail.com (Pete Lumbis) Date: Sat, 27 Oct 2012 17:00:46 -0400 Subject: IOS architecture In-Reply-To: References: Message-ID: You might want to take a look at the CEF book, which expands on this http://www.amazon.com/Cisco-Express-Forwarding-ebook/dp/B0015V9DQU/ both of these are still very accurate on how IOS operates today. The only major changes with IOS-XE is that IOS is now a process and packet forwarding is handled in hardware instead of software. For NX-OS and IOS-XR the software/operating system is wildly different and I think there is a definite gap in literature out there. On Fri, Oct 26, 2012 at 7:12 PM, Andrey Khomyakov wrote: > Does anyone know if there is an updated version of this book? Year 2000 > seems so distant now... > > http://www.amazon.com/dp/B0051TM4RC/ref=rdr_kindle_ext_tmb > > --Andrey From randy at psg.com Sat Oct 27 21:01:30 2012 From: randy at psg.com (Randy Bush) Date: Sun, 28 Oct 2012 06:01:30 +0900 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: > It's often cited as a headache to maintain the PTRs (not really, > automation ftw!) I think really it gets down to "how does it really > help?" why is my traffic between seattle and new york going through tokyo? randy From morrowc.lists at gmail.com Sun Oct 28 00:47:41 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 27 Oct 2012 20:47:41 -0400 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: On Sat, Oct 27, 2012 at 5:01 PM, Randy Bush wrote: >> It's often cited as a headache to maintain the PTRs (not really, >> automation ftw!) I think really it gets down to "how does it really >> help?" > > why is my traffic between seattle and new york going through tokyo? 'because someone forgot to rename the ptr' ? From nick at foobar.org Sun Oct 28 10:15:50 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 28 Oct 2012 10:15:50 +0000 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: <508D05D6.9030604@foobar.org> On 28/10/2012 01:47, Christopher Morrow wrote: > On Sat, Oct 27, 2012 at 5:01 PM, Randy Bush wrote: >>> It's often cited as a headache to maintain the PTRs (not really, >>> automation ftw!) I think really it gets down to "how does it really >>> help?" >> >> why is my traffic between seattle and new york going through tokyo? > > 'because someone forgot to rename the ptr' ? 'because it's the mid-2000s and I'm using ipv6?' From lukasz at bromirski.net Sun Oct 28 13:41:46 2012 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Sun, 28 Oct 2012 14:41:46 +0100 Subject: IOS architecture In-Reply-To: References: Message-ID: <5C5FA66D-E8A8-48B2-9A49-6AAAED1204D1@bromirski.net> On Oct 27, 2012, at 11:00 PM, Pete Lumbis wrote: > You might want to take a look at the CEF book, which expands on this > http://www.amazon.com/Cisco-Express-Forwarding-ebook/dp/B0015V9DQU/ > > both of these are still very accurate on how IOS operates today. The > only major changes with IOS-XE is that IOS is now a process and packet > forwarding is handled in hardware instead of software. On the IOS-XE it's no longer single process, when you're running in the modular version. It's getting complicated. > For NX-OS and IOS-XR the software/operating system is wildly different > and I think there is a definite gap in literature out there. For now, there's Cisco Live and techtorials about architecture and inner works. There will be a book, or two :) -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From rupertg at gmail.com Sun Oct 28 13:42:34 2012 From: rupertg at gmail.com (Rupert Goodwins) Date: Sun, 28 Oct 2012 13:42:34 +0000 Subject: IOS architecture In-Reply-To: References: Message-ID: On 27 October 2012 00:12, Andrey Khomyakov wrote: > Does anyone know if there is an updated version of this book? Year 2000 > seems so distant now... > > http://www.amazon.com/dp/B0051TM4RC/ref=rdr_kindle_ext_tmb > > --Andrey I asked an IOS expert of my acquaintance, and she said - ----------------------- That book is now well out of date, and although some of the information on CEF is still relevant, the 7500 platform is gone, and the 12k is replaced by the CRS. There are no plans from the authors (according to Russ White) to revisit it. The new 'big routers' now run IOS-XR, rather than the original IOS we know and love http://www.ciscopress.com/store/cisco-ios-xr-fundamentals-9781587052712 Then of course for the Data Centre, there's the Nexus platform, which has its own OS-- http://www.ciscopress.com/store/nx-os-and-cisco-nexus-switching-next-generat ion-data-9780132883627 However, to be honest, your best bet is to have a look through the Cisco Networkers--now called Cisco Live--presentations. These are now available publically for free for past events, and if you don't mind having a bit of a plough through, there is a wealth of information--including platform architecture sessions. http://packetlife.net/blog/2012/jun/4/cisco-live-presentations-available-fre e/ for info. Register here: https://www.ciscolive365.com/connect/publicDashboard.ww ------------------------------------ From owen at delong.com Sun Oct 28 17:10:08 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 28 Oct 2012 10:10:08 -0700 Subject: Google PTR? In-Reply-To: References: <508B5A72.30904@afxr.net> Message-ID: On Oct 27, 2012, at 11:28 , Christopher Morrow wrote: > On Sat, Oct 27, 2012 at 7:05 AM, Anurag Bhatia wrote: >> Hi Blair >> >> >> I guess that's pretty much because they don't really wish to put any info >> related to routers in public including location & circuit bandwidth which is >> often given major networks in PTR. >> > > more over, what help is it? I'm of two minds really about this: > 1) it's handy to say: the router in elbonia is being 'bad' > 2) it's just as simple to say: 'your router with interface ip 1.2.3.4 > is being bad' > (or: "everything through 1.2.3.4 is forked... plstofixkthxbi!") > True, but... It's handy to say foo-e1-kcks is hosed. Not as handy to say 2001:db8:5fe3:139a:6254:03ff:fe19:acf3 is hosed. > It's often cited as a headache to maintain the PTRs (not really, > automation ftw!) I think really it gets down to "how does it really > help?" > See above? Beyond that, it's also convenient if you're trying to correlate outages affecting more than just google. For example, if I'm getting complaints about access to google, yahoo, nymex, and edgar and traceroutes to all three of those show packet loss between routers in Dallas and routers in Atlanta, then I know I'm probably facing a fiber or carrier outage or partial outage along the Dallas to Atlanta path. I may be able to take independent action to reroute my traffic via a more northerly path to avoid that problem. Owen From sarah.nataf at gmail.com Mon Oct 29 09:54:10 2012 From: sarah.nataf at gmail.com (Sarah Nataf) Date: Mon, 29 Oct 2012 10:54:10 +0100 Subject: Belpak / Beltelecom contact to address a BGP hijacking issue? Message-ID: Hi all, Does anyone have a technical or peering contact at Belpak / Beltelecom (AS 66697) to address an apparent netblock hijacking issue? AS6697 is advertising the 2.2.2.0/24 address space which is under AS3215 management. We've tried to announce the same prefix but it's difficult to get the traffic back! No answer from people listed in the whois, no peeringDB information. Any suggestions? Thanks in advance, -- sarah From Valdis.Kletnieks at vt.edu Mon Oct 29 12:43:51 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 29 Oct 2012 08:43:51 -0400 Subject: IOS architecture In-Reply-To: Your message of "Sat, 27 Oct 2012 11:16:10 +0100." References: , Message-ID: <31508.1351514631@turing-police.cc.vt.edu> On Sat, 27 Oct 2012 11:16:10 +0100, "Darren O'Connor" said: > All vendors should be writing in depth architecture books. The Juniper MX > book is a great example. Tell us exactly what your product can do and we'll > likely use more of it On the flip side, if you document what your product is probably incapable of due to the design architecture, the salescritters won't be able to sell as many of them... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From aledm at qix.co.uk Mon Oct 29 14:01:43 2012 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 29 Oct 2012 14:01:43 +0000 Subject: IOS architecture In-Reply-To: <31508.1351514631@turing-police.cc.vt.edu> References: <31508.1351514631@turing-police.cc.vt.edu> Message-ID: On 29 October 2012 12:43, wrote: > On Sat, 27 Oct 2012 11:16:10 +0100, "Darren O'Connor" said: > > All vendors should be writing in depth architecture books. The Juniper > MX > > book is a great example. Tell us exactly what your product can do and > we'll > > likely use more of it > > On the flip side, if you document what your product is probably incapable > of > due to the design architecture, the salescritters won't be able to sell as > many > of them... :) > I think the biggest problem in that regard is the gap between what the switch or router architecture is capable of and what the current release of IOS actually supports. This is generally what appears on the "roadmap" but, historically, not all of it gets delivered in a timely manner, and some features aren't delivered at all before the hardware is superseded. Aled From rps at maine.edu Mon Oct 29 14:54:46 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 29 Oct 2012 10:54:46 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: The core issue here is TCP MSS. PMTUD is a dynamic process for adjusting MSS, but requires that ICMP be permitted to negotiate the connection. The realistic alternative, in a world that filters all ICMP traffic, is to manually rewrite the MSS. In IOS this can be achieved via "ip tcp adjust-mss" and on Linux-based systems, netfilter can be used to adjust MSS for example. Keep in mind that the MSS will be smaller than your MTU. Consider the following example: ip mtu 1480 ip tcp adjust-mss 1440 tunnel mode ipip IP packets have 20 bytes of overhead, leaving 1480 bytes for data. So for an IP-in-IP tunnel, you'd set your MTU of your tunnel interface to 1480. Subtract another 20 bytes for the tunneled IP header and 20 bytes (typical) for your TCP header and you're left with 1440 bytes for data in a TCP connection. So in this case we write the MSS as 1440. I use IP-in-IP as an example because it's simple. GRE tunnels can be a little more complex. While the GRE header is typically 4 bytes, it can grow up to 16 bytes depending on options used. So for a typical GRE tunnel (4 byte header), you would subtract 20 bytes for the IP header and 4 bytes for the GRE header from your base MTU of 1500. This would mean an MTU of 1476, and a TCP MMS of 1436. Keep in mind that a TCP header can be up to 60 bytes in length, so you may want to go higher than the typical 20 bytes for your MSS if you're seeing problems. On Tue, Oct 23, 2012 at 10:07 AM, Templin, Fred L wrote: > Hi Roland, > >> -----Original Message----- >> From: Dobbins, Roland [mailto:rdobbins at arbor.net] >> Sent: Monday, October 22, 2012 6:49 PM >> To: NANOG list >> Subject: Re: IP tunnel MTU >> >> >> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: >> >> > Since tunnels always reduce the effective MTU seen by data packets due >> to the encapsulation overhead, the only two ways to accommodate >> > the tunnel MTU is either through the use of path MTU discovery or >> through fragmentation and reassembly. >> >> Actually, you can set your tunnel MTU manually. >> >> For example, the typical MTU folks set for a GRE tunnel is 1476. > > Yes; I was aware of this. But, what I want to get to is > setting the tunnel MTU to infinity. > >> This isn't a new issue; it's been around ever since tunneling technologies >> have been around, and tons have been written on this topic. Look at your >> various router/switch vendor Web sites, archives of this list and others, >> etc. > > Sure. I've written a fair amount about it too over the span > of the last ten years. What is new is that there is now a > solution near at hand. > >> So, it's been known about, dealt with, and documented for a long time. In >> terms of doing something about it, the answer there is a) to allow the >> requisite ICMP for PMTU-D to work to/through any networks within your span >> of administrative control and b) > > That does you no good if there is some other network further > beyond your span of administrative control that does not allow > the ICMP PTBs through. And, studies have shown this to be the > case in a non-trivial number of instances. > >> b) adjusting your own tunnel MTUs to >> appropriate values based upon experimentation. > > Adjust it down to what? 1280? Then, if your tunnel with the > adjusted MTU enters another tunnel with its own adjusted MTU > there is an MTU underflow that might not get reported if the > ICMP PTB messages are lost. An alternative is to use IP > fragmentation, but recent studies have shown that more and > more operators are unconditionally dropping IPv6 fragments > and IPv4 fragmentation is not an option due to wrapping IDs > at high data rates. > > Nested tunnels-within-tunnels occur in operational scenarios > more and more, and adjusting the MTU for only one tunnel in > the nesting does you no good if there are other tunnels that > adjust their own MTUs. > >> Enterprise endpoint networks are notorious for blocking *all* ICMP (as >> well as TCP/53 DNS) at their edges due to 'security' misinformation >> propagated by Confused Information Systems Security Professionals and >> their ilk. Be sure that your own network policies aren't part of the >> problem affecting your userbase, as well as anyone else with a need to >> communicate with properties on your network via tunnels. > > Again, all an operator can control is that which is within their > own administrative domain. That does no good for ICMPs that are > lost beyond their administrative domain. > > Thanks - Fred > fred.l.templin at boeing.com > >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Luck is the residue of opportunity and design. >> >> -- John Milton >> > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From Fred.L.Templin at boeing.com Mon Oct 29 16:39:19 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 29 Oct 2012 09:39:19 -0700 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: Hi Ray, MSS rewriting has been well known and broadly applied for a long time now, but only applies to TCP. The subject of MSS rewriting comes up all the time in the IETF wg discussions, but has failed to reach consensus as a long-term alternative. Plus, MSS rewriting does no good for tunnels-within-tunnels. If the innermost tunnel rewrites MSS to a value that *it* thinks is safe there is no guarantee that the packets will fit within any outer tunnels that occur further down the line. What I want to get to is an indefinite tunnel MTU; i.e., admit any packet into the tunnel regardless of its size then make any necessary adaptations from within the tunnel. That is exactly what SEAL does: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Thanks - Fred fred.l.templin at boeing.com > -----Original Message----- > From: Ray Soucy [mailto:rps at maine.edu] > Sent: Monday, October 29, 2012 7:55 AM > To: Templin, Fred L > Cc: Dobbins, Roland; NANOG list > Subject: Re: IP tunnel MTU > > The core issue here is TCP MSS. PMTUD is a dynamic process for > adjusting MSS, but requires that ICMP be permitted to negotiate the > connection. The realistic alternative, in a world that filters all > ICMP traffic, is to manually rewrite the MSS. In IOS this can be > achieved via "ip tcp adjust-mss" and on Linux-based systems, netfilter > can be used to adjust MSS for example. > > Keep in mind that the MSS will be smaller than your MTU. > Consider the following example: > > ip mtu 1480 > ip tcp adjust-mss 1440 > tunnel mode ipip > > IP packets have 20 bytes of overhead, leaving 1480 bytes for data. So > for an IP-in-IP tunnel, you'd set your MTU of your tunnel interface to > 1480. Subtract another 20 bytes for the tunneled IP header and 20 > bytes (typical) for your TCP header and you're left with 1440 bytes > for data in a TCP connection. So in this case we write the MSS as > 1440. > > I use IP-in-IP as an example because it's simple. GRE tunnels can be > a little more complex. While the GRE header is typically 4 bytes, it > can grow up to 16 bytes depending on options used. > > So for a typical GRE tunnel (4 byte header), you would subtract 20 > bytes for the IP header and 4 bytes for the GRE header from your base > MTU of 1500. This would mean an MTU of 1476, and a TCP MMS of 1436. > > Keep in mind that a TCP header can be up to 60 bytes in length, so you > may want to go higher than the typical 20 bytes for your MSS if you're > seeing problems. > > > > > On Tue, Oct 23, 2012 at 10:07 AM, Templin, Fred L > wrote: > > Hi Roland, > > > >> -----Original Message----- > >> From: Dobbins, Roland [mailto:rdobbins at arbor.net] > >> Sent: Monday, October 22, 2012 6:49 PM > >> To: NANOG list > >> Subject: Re: IP tunnel MTU > >> > >> > >> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: > >> > >> > Since tunnels always reduce the effective MTU seen by data packets > due > >> to the encapsulation overhead, the only two ways to accommodate > >> > the tunnel MTU is either through the use of path MTU discovery or > >> through fragmentation and reassembly. > >> > >> Actually, you can set your tunnel MTU manually. > >> > >> For example, the typical MTU folks set for a GRE tunnel is 1476. > > > > Yes; I was aware of this. But, what I want to get to is > > setting the tunnel MTU to infinity. > > > >> This isn't a new issue; it's been around ever since tunneling > technologies > >> have been around, and tons have been written on this topic. Look at > your > >> various router/switch vendor Web sites, archives of this list and > others, > >> etc. > > > > Sure. I've written a fair amount about it too over the span > > of the last ten years. What is new is that there is now a > > solution near at hand. > > > >> So, it's been known about, dealt with, and documented for a long time. > In > >> terms of doing something about it, the answer there is a) to allow the > >> requisite ICMP for PMTU-D to work to/through any networks within your > span > >> of administrative control and b) > > > > That does you no good if there is some other network further > > beyond your span of administrative control that does not allow > > the ICMP PTBs through. And, studies have shown this to be the > > case in a non-trivial number of instances. > > > >> b) adjusting your own tunnel MTUs to > >> appropriate values based upon experimentation. > > > > Adjust it down to what? 1280? Then, if your tunnel with the > > adjusted MTU enters another tunnel with its own adjusted MTU > > there is an MTU underflow that might not get reported if the > > ICMP PTB messages are lost. An alternative is to use IP > > fragmentation, but recent studies have shown that more and > > more operators are unconditionally dropping IPv6 fragments > > and IPv4 fragmentation is not an option due to wrapping IDs > > at high data rates. > > > > Nested tunnels-within-tunnels occur in operational scenarios > > more and more, and adjusting the MTU for only one tunnel in > > the nesting does you no good if there are other tunnels that > > adjust their own MTUs. > > > >> Enterprise endpoint networks are notorious for blocking *all* ICMP (as > >> well as TCP/53 DNS) at their edges due to 'security' misinformation > >> propagated by Confused Information Systems Security Professionals and > >> their ilk. Be sure that your own network policies aren't part of the > >> problem affecting your userbase, as well as anyone else with a need to > >> communicate with properties on your network via tunnels. > > > > Again, all an operator can control is that which is within their > > own administrative domain. That does no good for ICMPs that are > > lost beyond their administrative domain. > > > > Thanks - Fred > > fred.l.templin at boeing.com > > > >> ----------------------------------------------------------------------- > >> Roland Dobbins // > >> > >> Luck is the residue of opportunity and design. > >> > >> -- John Milton > >> > > > > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From bmanning at vacation.karoshi.com Mon Oct 29 17:07:43 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Oct 2012 17:07:43 +0000 Subject: the little ssh that (sometimes) couldn't Message-ID: <20121029170743.GB2527@vacation.karoshi.com.> corruption! http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html /bill From me at anuragbhatia.com Mon Oct 29 18:03:56 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 29 Oct 2012 23:33:56 +0530 Subject: Belpak / Beltelecom contact to address a BGP hijacking issue? In-Reply-To: References: Message-ID: Hello Sarah Seems like they are not advertising it anymore. AS6697 has transit from Level3 and peering/transit from HE. Both of them show path to AS3215 for that prefix now. http://lookingglass.level3.net/ BGP query on all sites seems OK for now. Also same on results from Oregon as well as HE. Infact HE is taking 1299 5511 3215 ...way longer then direct 6697 if existed. Surely they were getting wrong announcement as per http://bgp.he.net/net/2.2.2.0/24 - which is updated once in 24hrs. So likely issue resolved? On Mon, Oct 29, 2012 at 3:24 PM, Sarah Nataf wrote: > Hi all, > > Does anyone have a technical or peering contact at Belpak / Beltelecom > (AS 66697) to address > an apparent netblock hijacking issue? > > AS6697 is advertising the 2.2.2.0/24 address space which is under > AS3215 management. > We've tried to announce the same prefix but it's difficult to get the > traffic back! > > No answer from people listed in the whois, no peeringDB information. > Any suggestions? > > Thanks in advance, > -- > sarah > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From george.herbert at gmail.com Mon Oct 29 18:35:56 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 29 Oct 2012 11:35:56 -0700 Subject: the little ssh that (sometimes) couldn't In-Reply-To: <508eb890.85712b0a.05cf.ffffded2SMTPIN_ADDED@mx.google.com> References: <508eb890.85712b0a.05cf.ffffded2SMTPIN_ADDED@mx.google.com> Message-ID: On Mon, Oct 29, 2012 at 10:07 AM, wrote: > > corruption! > > > http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html > > > /bill This is an excellent full-stack debugging war story. Thanks for posting it, Bill. -- -george william herbert george.herbert at gmail.com From sylvie at newnog.org Mon Oct 29 18:40:34 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 29 Oct 2012 14:40:34 -0400 Subject: [NANOG-announce] 2012 NANOG Election Results Message-ID: *Greetings NANOG Colleagues, As usual for our October meetings, there has been a lot happening with our elections process and more announcements to come over the next few days. We wanted to give you a quick heads-up. Huge thank yous to our Executive Director, Betty Burke, our NANOG Secretariat, Florencia Dazzi and Karen Moore, the Verilan team, the SWANK team, and our technical coordinators Tim Pozar and Matt Peterson for a world-class event in Dallas. Elections Our annual election was held during NANOG 56. Steve Feldman, Dan Golding and Mike Smith were elected to two-year terms on the Board of Directors. All three proposed amendments to our bylaws also passed. The Board appointed its officers for the coming year. I have been re-appointed Chair, Mike Smith is the Vice-Chair, Duane Wessels is Treasurer and DC liaison, Steve Feldman is Secretary, Dan Golding is PC liaison and Steve Gibbard is CC liaison. Committee Appointments The Communications, Development and Program Committees selection process is drawing to a close. Offers have been extended to candidates on October 25 and we expect to have all confirmations in the next 24-48 hours. A formal announcement of their respective composition will follow this week. We wish to thank everyone who volunteered to serve either on the NANOG Board of Directors or on one of its Committees. NANOG is truly an organization that depends on the ongoing enthusiasm and support of its community: thank you for attending NANOG 56 live or via webcast and for contributing regularly to our mailing lists. The coming year is exciting. There is much to be done as we execute our three-year strategic plan. We will communicate progress regularly.* * * *Best regards, * Sylvie -- Sylvie LaPerriere Chair, NANOG Board of Directors www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jlewis at lewis.org Mon Oct 29 18:54:32 2012 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 29 Oct 2012 14:54:32 -0400 (EDT) Subject: the little ssh that (sometimes) couldn't In-Reply-To: <20121029170743.GB2527@vacation.karoshi.com.> References: <20121029170743.GB2527@vacation.karoshi.com.> Message-ID: On Mon, 29 Oct 2012 bmanning at vacation.karoshi.com wrote: > corruption! > > http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html Bush league. I debugged a similar issue on Sprint's network about 15 years ago, also nailing it down to which router/router hop had the problem (a misconfigured interface that couldn't pass certain bit patterns and was causing a particular file we were hosting for a customer to be non-downloadable by any client who's packets used the bad path), also using ping, but with a pattern much more interesting than large packets of nulls...and I had to figure out the problematic pattern before I could do the ping tests. But if you want really bizzare, this one never got solved to my satisfaction. http://mailman.nanog.org/pipermail/nanog/2008-August/002788.html ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Sean.Pedersen at usairways.com Mon Oct 29 19:10:40 2012 From: Sean.Pedersen at usairways.com (Pedersen, Sean) Date: Mon, 29 Oct 2012 12:10:40 -0700 Subject: Network scan tool/appliance horror stories Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> We're evaluating several tools at the moment, and one vendor wants to dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the works. I was curious if anyone had any particularly gruesome horror stories of scanning tools run amok. From rdrake at direcpath.com Mon Oct 29 19:12:11 2012 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 29 Oct 2012 15:12:11 -0400 Subject: the little ssh that (sometimes) couldn't In-Reply-To: References: <20121029170743.GB2527@vacation.karoshi.com.> Message-ID: <508ED50B.1030608@direcpath.com> On 10/29/2012 02:54 PM, Jon Lewis wrote: > > Bush league. I debugged a similar issue on Sprint's network about 15 > years ago, also nailing it down to which router/router hop had the problem When I was working for Sprint about 12 years ago, we had a circuit where the customer complained that we were blocking executable downloads. We essentially dismissed his complaints because they were ridiculous. We would test his T1 and it would show everything fine. I was willing to entertain his concern because it sounded weird and he had a UNIX box I could login to. Running wget I saw the same issues. If I zipped a file I could download it without issue, anything that was an exe would not. We narrowed it down to 2-4 bytes of the exe header that the circuit just wouldn't pass. Called the local telco and had them test the circuit from the customer prem, they found errors on the reverse. We fixed it and he could download executables again. I got an award for persistence and the customer canceled his account. From rps at maine.edu Mon Oct 29 19:17:46 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 29 Oct 2012 15:17:46 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: Sorry, glanced at this and thought it was someone having problems with tunnel MTU without adjusting TCP MSS. Nice work, though my preference is to avoid tunnels at all costs :-) On Mon, Oct 29, 2012 at 12:39 PM, Templin, Fred L wrote: > Hi Ray, > > MSS rewriting has been well known and broadly applied for a long > time now, but only applies to TCP. The subject of MSS rewriting > comes up all the time in the IETF wg discussions, but has failed > to reach consensus as a long-term alternative. > > Plus, MSS rewriting does no good for tunnels-within-tunnels. If > the innermost tunnel rewrites MSS to a value that *it* thinks is > safe there is no guarantee that the packets will fit within any > outer tunnels that occur further down the line. > > What I want to get to is an indefinite tunnel MTU; i.e., admit > any packet into the tunnel regardless of its size then make any > necessary adaptations from within the tunnel. That is exactly > what SEAL does: > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > Thanks - Fred > fred.l.templin at boeing.com > >> -----Original Message----- >> From: Ray Soucy [mailto:rps at maine.edu] >> Sent: Monday, October 29, 2012 7:55 AM >> To: Templin, Fred L >> Cc: Dobbins, Roland; NANOG list >> Subject: Re: IP tunnel MTU >> >> The core issue here is TCP MSS. PMTUD is a dynamic process for >> adjusting MSS, but requires that ICMP be permitted to negotiate the >> connection. The realistic alternative, in a world that filters all >> ICMP traffic, is to manually rewrite the MSS. In IOS this can be >> achieved via "ip tcp adjust-mss" and on Linux-based systems, netfilter >> can be used to adjust MSS for example. >> >> Keep in mind that the MSS will be smaller than your MTU. >> Consider the following example: >> >> ip mtu 1480 >> ip tcp adjust-mss 1440 >> tunnel mode ipip >> >> IP packets have 20 bytes of overhead, leaving 1480 bytes for data. So >> for an IP-in-IP tunnel, you'd set your MTU of your tunnel interface to >> 1480. Subtract another 20 bytes for the tunneled IP header and 20 >> bytes (typical) for your TCP header and you're left with 1440 bytes >> for data in a TCP connection. So in this case we write the MSS as >> 1440. >> >> I use IP-in-IP as an example because it's simple. GRE tunnels can be >> a little more complex. While the GRE header is typically 4 bytes, it >> can grow up to 16 bytes depending on options used. >> >> So for a typical GRE tunnel (4 byte header), you would subtract 20 >> bytes for the IP header and 4 bytes for the GRE header from your base >> MTU of 1500. This would mean an MTU of 1476, and a TCP MMS of 1436. >> >> Keep in mind that a TCP header can be up to 60 bytes in length, so you >> may want to go higher than the typical 20 bytes for your MSS if you're >> seeing problems. >> >> >> >> >> On Tue, Oct 23, 2012 at 10:07 AM, Templin, Fred L >> wrote: >> > Hi Roland, >> > >> >> -----Original Message----- >> >> From: Dobbins, Roland [mailto:rdobbins at arbor.net] >> >> Sent: Monday, October 22, 2012 6:49 PM >> >> To: NANOG list >> >> Subject: Re: IP tunnel MTU >> >> >> >> >> >> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: >> >> >> >> > Since tunnels always reduce the effective MTU seen by data packets >> due >> >> to the encapsulation overhead, the only two ways to accommodate >> >> > the tunnel MTU is either through the use of path MTU discovery or >> >> through fragmentation and reassembly. >> >> >> >> Actually, you can set your tunnel MTU manually. >> >> >> >> For example, the typical MTU folks set for a GRE tunnel is 1476. >> > >> > Yes; I was aware of this. But, what I want to get to is >> > setting the tunnel MTU to infinity. >> > >> >> This isn't a new issue; it's been around ever since tunneling >> technologies >> >> have been around, and tons have been written on this topic. Look at >> your >> >> various router/switch vendor Web sites, archives of this list and >> others, >> >> etc. >> > >> > Sure. I've written a fair amount about it too over the span >> > of the last ten years. What is new is that there is now a >> > solution near at hand. >> > >> >> So, it's been known about, dealt with, and documented for a long time. >> In >> >> terms of doing something about it, the answer there is a) to allow the >> >> requisite ICMP for PMTU-D to work to/through any networks within your >> span >> >> of administrative control and b) >> > >> > That does you no good if there is some other network further >> > beyond your span of administrative control that does not allow >> > the ICMP PTBs through. And, studies have shown this to be the >> > case in a non-trivial number of instances. >> > >> >> b) adjusting your own tunnel MTUs to >> >> appropriate values based upon experimentation. >> > >> > Adjust it down to what? 1280? Then, if your tunnel with the >> > adjusted MTU enters another tunnel with its own adjusted MTU >> > there is an MTU underflow that might not get reported if the >> > ICMP PTB messages are lost. An alternative is to use IP >> > fragmentation, but recent studies have shown that more and >> > more operators are unconditionally dropping IPv6 fragments >> > and IPv4 fragmentation is not an option due to wrapping IDs >> > at high data rates. >> > >> > Nested tunnels-within-tunnels occur in operational scenarios >> > more and more, and adjusting the MTU for only one tunnel in >> > the nesting does you no good if there are other tunnels that >> > adjust their own MTUs. >> > >> >> Enterprise endpoint networks are notorious for blocking *all* ICMP (as >> >> well as TCP/53 DNS) at their edges due to 'security' misinformation >> >> propagated by Confused Information Systems Security Professionals and >> >> their ilk. Be sure that your own network policies aren't part of the >> >> problem affecting your userbase, as well as anyone else with a need to >> >> communicate with properties on your network via tunnels. >> > >> > Again, all an operator can control is that which is within their >> > own administrative domain. That does no good for ICMPs that are >> > lost beyond their administrative domain. >> > >> > Thanks - Fred >> > fred.l.templin at boeing.com >> > >> >> ----------------------------------------------------------------------- >> >> Roland Dobbins // >> >> >> >> Luck is the residue of opportunity and design. >> >> >> >> -- John Milton >> >> >> > >> > >> >> >> >> -- >> Ray Patrick Soucy >> Network Engineer >> University of Maine System >> >> T: 207-561-3526 >> F: 207-561-3531 >> >> MaineREN, Maine's Research and Education Network >> www.maineren.net -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From streiner at cluebyfour.org Mon Oct 29 19:25:08 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 29 Oct 2012 15:25:08 -0400 (EDT) Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: On Mon, 29 Oct 2012, Pedersen, Sean wrote: > We're evaluating several tools at the moment, and one vendor wants to > dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, > the works. I was curious if anyone had any particularly gruesome horror > stories of scanning tools run amok. If you have any overloaded/under-powered network gear, such as stateful firewalls and routers that do lots of NAT, you might find them very quickly, depending on how aggressive the scanning tool is. There might also be devices out there that, while possibly lightly loaded, can reach some minimally documented resource threshold under a very aggressive scan, and subsequently tip over. Also, if you're doing IPv6, the performance metrics for many network devices can be a bit more of a moving target. jms From sh.vahabzadeh at gmail.com Mon Oct 29 19:32:51 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 29 Oct 2012 23:02:51 +0330 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: Hi there, I have the same problem in my network, I have GRE tunnel for transfering users real internet traffic, they have problems with browsing websites like yahoo.com or microsoft.com. I had to set ip mtu 1500 to solve it, and it occurs fragmantation... Thanks On Mon, Oct 29, 2012 at 10:47 PM, Ray Soucy wrote: > Sorry, glanced at this and thought it was someone having problems with > tunnel MTU without adjusting TCP MSS. > > Nice work, though my preference is to avoid tunnels at all costs :-) > > > > > On Mon, Oct 29, 2012 at 12:39 PM, Templin, Fred L > wrote: > > Hi Ray, > > > > MSS rewriting has been well known and broadly applied for a long > > time now, but only applies to TCP. The subject of MSS rewriting > > comes up all the time in the IETF wg discussions, but has failed > > to reach consensus as a long-term alternative. > > > > Plus, MSS rewriting does no good for tunnels-within-tunnels. If > > the innermost tunnel rewrites MSS to a value that *it* thinks is > > safe there is no guarantee that the packets will fit within any > > outer tunnels that occur further down the line. > > > > What I want to get to is an indefinite tunnel MTU; i.e., admit > > any packet into the tunnel regardless of its size then make any > > necessary adaptations from within the tunnel. That is exactly > > what SEAL does: > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > > > Thanks - Fred > > fred.l.templin at boeing.com > > > >> -----Original Message----- > >> From: Ray Soucy [mailto:rps at maine.edu] > >> Sent: Monday, October 29, 2012 7:55 AM > >> To: Templin, Fred L > >> Cc: Dobbins, Roland; NANOG list > >> Subject: Re: IP tunnel MTU > >> > >> The core issue here is TCP MSS. PMTUD is a dynamic process for > >> adjusting MSS, but requires that ICMP be permitted to negotiate the > >> connection. The realistic alternative, in a world that filters all > >> ICMP traffic, is to manually rewrite the MSS. In IOS this can be > >> achieved via "ip tcp adjust-mss" and on Linux-based systems, netfilter > >> can be used to adjust MSS for example. > >> > >> Keep in mind that the MSS will be smaller than your MTU. > >> Consider the following example: > >> > >> ip mtu 1480 > >> ip tcp adjust-mss 1440 > >> tunnel mode ipip > >> > >> IP packets have 20 bytes of overhead, leaving 1480 bytes for data. So > >> for an IP-in-IP tunnel, you'd set your MTU of your tunnel interface to > >> 1480. Subtract another 20 bytes for the tunneled IP header and 20 > >> bytes (typical) for your TCP header and you're left with 1440 bytes > >> for data in a TCP connection. So in this case we write the MSS as > >> 1440. > >> > >> I use IP-in-IP as an example because it's simple. GRE tunnels can be > >> a little more complex. While the GRE header is typically 4 bytes, it > >> can grow up to 16 bytes depending on options used. > >> > >> So for a typical GRE tunnel (4 byte header), you would subtract 20 > >> bytes for the IP header and 4 bytes for the GRE header from your base > >> MTU of 1500. This would mean an MTU of 1476, and a TCP MMS of 1436. > >> > >> Keep in mind that a TCP header can be up to 60 bytes in length, so you > >> may want to go higher than the typical 20 bytes for your MSS if you're > >> seeing problems. > >> > >> > >> > >> > >> On Tue, Oct 23, 2012 at 10:07 AM, Templin, Fred L > >> wrote: > >> > Hi Roland, > >> > > >> >> -----Original Message----- > >> >> From: Dobbins, Roland [mailto:rdobbins at arbor.net] > >> >> Sent: Monday, October 22, 2012 6:49 PM > >> >> To: NANOG list > >> >> Subject: Re: IP tunnel MTU > >> >> > >> >> > >> >> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: > >> >> > >> >> > Since tunnels always reduce the effective MTU seen by data packets > >> due > >> >> to the encapsulation overhead, the only two ways to accommodate > >> >> > the tunnel MTU is either through the use of path MTU discovery or > >> >> through fragmentation and reassembly. > >> >> > >> >> Actually, you can set your tunnel MTU manually. > >> >> > >> >> For example, the typical MTU folks set for a GRE tunnel is 1476. > >> > > >> > Yes; I was aware of this. But, what I want to get to is > >> > setting the tunnel MTU to infinity. > >> > > >> >> This isn't a new issue; it's been around ever since tunneling > >> technologies > >> >> have been around, and tons have been written on this topic. Look at > >> your > >> >> various router/switch vendor Web sites, archives of this list and > >> others, > >> >> etc. > >> > > >> > Sure. I've written a fair amount about it too over the span > >> > of the last ten years. What is new is that there is now a > >> > solution near at hand. > >> > > >> >> So, it's been known about, dealt with, and documented for a long > time. > >> In > >> >> terms of doing something about it, the answer there is a) to allow > the > >> >> requisite ICMP for PMTU-D to work to/through any networks within your > >> span > >> >> of administrative control and b) > >> > > >> > That does you no good if there is some other network further > >> > beyond your span of administrative control that does not allow > >> > the ICMP PTBs through. And, studies have shown this to be the > >> > case in a non-trivial number of instances. > >> > > >> >> b) adjusting your own tunnel MTUs to > >> >> appropriate values based upon experimentation. > >> > > >> > Adjust it down to what? 1280? Then, if your tunnel with the > >> > adjusted MTU enters another tunnel with its own adjusted MTU > >> > there is an MTU underflow that might not get reported if the > >> > ICMP PTB messages are lost. An alternative is to use IP > >> > fragmentation, but recent studies have shown that more and > >> > more operators are unconditionally dropping IPv6 fragments > >> > and IPv4 fragmentation is not an option due to wrapping IDs > >> > at high data rates. > >> > > >> > Nested tunnels-within-tunnels occur in operational scenarios > >> > more and more, and adjusting the MTU for only one tunnel in > >> > the nesting does you no good if there are other tunnels that > >> > adjust their own MTUs. > >> > > >> >> Enterprise endpoint networks are notorious for blocking *all* ICMP > (as > >> >> well as TCP/53 DNS) at their edges due to 'security' misinformation > >> >> propagated by Confused Information Systems Security Professionals and > >> >> their ilk. Be sure that your own network policies aren't part of the > >> >> problem affecting your userbase, as well as anyone else with a need > to > >> >> communicate with properties on your network via tunnels. > >> > > >> > Again, all an operator can control is that which is within their > >> > own administrative domain. That does no good for ICMPs that are > >> > lost beyond their administrative domain. > >> > > >> > Thanks - Fred > >> > fred.l.templin at boeing.com > >> > > >> >> > ----------------------------------------------------------------------- > >> >> Roland Dobbins // > > >> >> > >> >> Luck is the residue of opportunity and design. > >> >> > >> >> -- John Milton > >> >> > >> > > >> > > >> > >> > >> > >> -- > >> Ray Patrick Soucy > >> Network Engineer > >> University of Maine System > >> > >> T: 207-561-3526 > >> F: 207-561-3531 > >> > >> MaineREN, Maine's Research and Education Network > >> www.maineren.net > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From baconzombie at gmail.com Mon Oct 29 19:40:50 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Mon, 29 Oct 2012 19:40:50 +0000 Subject: Network scan tool/appliance horror stories In-Reply-To: References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: It all depends on what tools they are using and how you have your system setup. Both NMAP and Nessus can check system\service to see if common accounts have default or non password at all. This can cause these accounts to be locked out. There are other "exploits" that can cause systems\services to be DOS'd but these normally have to be enabled. Best to get a statement of works from them which should list all the tools including options they will be using. They also should be able to hand over a raw dump of ALL commands run during the testing. On 29 October 2012 19:25, Justin M. Streiner wrote: > On Mon, 29 Oct 2012, Pedersen, Sean wrote: > > We're evaluating several tools at the moment, and one vendor wants to >> dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the >> works. I was curious if anyone had any particularly gruesome horror stories >> of scanning tools run amok. >> > > If you have any overloaded/under-powered network gear, such as stateful > firewalls and routers that do lots of NAT, you might find them very > quickly, depending on how aggressive the scanning tool is. There might > also be devices out there that, while possibly lightly loaded, can reach > some minimally documented resource threshold under a very aggressive scan, > and subsequently tip over. > > Also, if you're doing IPv6, the performance metrics for many network > devices can be a bit more of a moving target. > > jms > > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From prt at prt.org Mon Oct 29 19:43:41 2012 From: prt at prt.org (Paul Thornton) Date: Mon, 29 Oct 2012 19:43:41 +0000 Subject: Network scan tool/appliance horror stories In-Reply-To: References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <508EDC6D.2060507@prt.org> On 29/10/2012 19:25, Justin M. Streiner wrote: > Also, if you're doing IPv6, the performance metrics for many network > devices can be a bit more of a moving target. I'd almost be tempted to set up a few machines doing v6 only on the LAN, with some trivial to exploit telnet/SNMP access then invite them to scan the LAN and see if said machines are picked up. My experience of these things a year or two ago was that most of these companies thought everyone had an internal flat IPv4 network in RFC1918 space and that was that. YMMV of course. Paul. -- Paul Thornton From sylvie at newnog.org Mon Oct 29 19:43:28 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 29 Oct 2012 15:43:28 -0400 Subject: [NANOG-announce] 2012 Program Committee Appointments Announcement Message-ID: *Greetings NANOG Colleagues, * * The Board has completed the Program Committee selection process. This year, twenty members submitted their candidacies for eight available positions. We want to thank each and every one of them for considering this important service to our community and encourage them to try for the next selection cycle. We are pleased to announce the two-year term appointment of Philippe Couture, Greg Dendy, Ryan Donnelly, Chris Grundemann, Elisa Jasinska, Anton Kapela, John van Oppen and Dave Temkin to the Program Committee. We also want to thank and recognize the contribution of Kevin Epperson for his service during 2010-2012 and the contributions of Nina Bargisen, Tom Daly, Dave Meyer and Tom Scholl for their 4-year service on the 2008-2012 Program Committees. In the coming weeks, the new Program Committee will hold its first meeting and select a Chair and a Vice-Chair. On behalf of the Board, *Sylvie -- Sylvie LaPerriere Chair, NANOG Board of Directors www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jared at puck.nether.net Mon Oct 29 19:43:52 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Oct 2012 15:43:52 -0400 Subject: Network scan tool/appliance horror stories In-Reply-To: References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: I heard a story in the past year of someone that had a system get scanned and it opened a ticket with their IT department for each time they scanned them. Eventually the IT department system crashed due to the excessive number of tickets being opened by their scanning tool. The network was properly exempted from the future scans after the system had to be recovered from backup. - Jared > LOAD "*",8,1 ^^^^^^^^^^^^^ yay From dwhite at olp.net Mon Oct 29 19:46:46 2012 From: dwhite at olp.net (Dan White) Date: Mon, 29 Oct 2012 14:46:46 -0500 Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <20121029194646.GD13937@dan.olp.net> On 10/29/12?12:10?-0700, Pedersen, Sean wrote: >We're evaluating several tools at the moment, and one vendor wants to >dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the >works. I was curious if anyone had any particularly gruesome horror >stories of scanning tools run amok. http://www.tulsaworld.com/news/article.aspx?subjectid=334&articleid=20121002_11_A1_CUTLIN325691 A > layer 7 failure. Make sure all members of your organization are aware of your plans. -- Dan White From jmaimon at ttec.com Mon Oct 29 19:46:57 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 29 Oct 2012 15:46:57 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: <508EDD31.4030100@ttec.com> Templin, Fred L wrote: > Yes; I was aware of this. But, what I want to get to is > setting the tunnel MTU to infinity. Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. I agree. Joe From jared at puck.nether.net Mon Oct 29 20:01:56 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Oct 2012 16:01:56 -0400 Subject: IP tunnel MTU In-Reply-To: <508EDD31.4030100@ttec.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> Message-ID: On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote: > > > Templin, Fred L wrote: > >> Yes; I was aware of this. But, what I want to get to is >> setting the tunnel MTU to infinity. > > > Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. > > I agree. Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. - Jared From tdurack at gmail.com Mon Oct 29 20:06:29 2012 From: tdurack at gmail.com (Tim Durack) Date: Mon, 29 Oct 2012 16:06:29 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> Message-ID: On Mon, Oct 29, 2012 at 4:01 PM, Jared Mauch wrote: > > On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote: > >> >> >> Templin, Fred L wrote: >> >>> Yes; I was aware of this. But, what I want to get to is >>> setting the tunnel MTU to infinity. >> >> >> Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. >> >> I agree. > > > Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. > > - Jared Wait till you get started on "fixing" the "security" consultants. -- Tim:> From sylvie at newnog.org Mon Oct 29 20:08:53 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 29 Oct 2012 16:08:53 -0400 Subject: [NANOG-announce] 2012 Development Committee Appointments Announcement Message-ID: *Greetings NANOG Colleagues, * * * *The Board has completed the Development Committee selection process for 2012. We are pleased to announce the two-year term appointment of Michael Buchner, Jezzibell Gilmore, Gina Haspillaire and Misako Manca and the one-year term appointment of Michael Rascoe to the Development Committee. We also want to thank and recognize Cat Rodery for designing the members benefits during her tenure as Membership Vice Chair. In the coming weeks, the new Development Committee will hold its first meeting and select a Chair and a Vice-Chair. On behalf of the Board, * -- Sylvie LaPerriere Chair, NANOG Board of Directors www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From bmanning at vacation.karoshi.com Mon Oct 29 20:28:32 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Oct 2012 20:28:32 +0000 Subject: IP tunnel MTU In-Reply-To: <508EDD31.4030100@ttec.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> Message-ID: <20121029202832.GA1970@vacation.karoshi.com.> On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote: > > > Templin, Fred L wrote: > > >Yes; I was aware of this. But, what I want to get to is > >setting the tunnel MTU to infinity. > > > Essentially, its time the network matured to the point where > inter-networking actually works (again), seamlessly. > > I agree. > > Joe you mean its safe to turn off the VPNs? /bill From jmaimon at ttec.com Mon Oct 29 20:43:50 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 29 Oct 2012 16:43:50 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> Message-ID: <508EEA86.2020007@ttec.com> Jared Mauch wrote: > > On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote: > >> >> >> Templin, Fred L wrote: >> >>> Yes; I was aware of this. But, what I want to get to is >>> setting the tunnel MTU to infinity. >> >> >> Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. >> >> I agree. > > > Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. > > - Jared > ICMP is just not the way it is ever going to work. Joe From jmaimon at ttec.com Mon Oct 29 20:44:40 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 29 Oct 2012 16:44:40 -0400 Subject: IP tunnel MTU In-Reply-To: <20121029202832.GA1970@vacation.karoshi.com.> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <20121029202832.GA1970@vacation.karoshi.com.> Message-ID: <508EEAB8.9080209@ttec.com> bmanning at vacation.karoshi.com wrote: > On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote: >> >> >> Templin, Fred L wrote: >> >>> Yes; I was aware of this. But, what I want to get to is >>> setting the tunnel MTU to infinity. >> >> >> Essentially, its time the network matured to the point where >> inter-networking actually works (again), seamlessly. >> >> I agree. >> >> Joe > > you mean its safe to turn off the VPNs? > > /bill > > Quite the reverse. Joe From jared at puck.nether.net Mon Oct 29 20:49:19 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Oct 2012 16:49:19 -0400 Subject: IP tunnel MTU In-Reply-To: <508EEA86.2020007@ttec.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <508EEA86.2020007@ttec.com> Message-ID: <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> On Oct 29, 2012, at 4:43 PM, Joe Maimon wrote: > > > Jared Mauch wrote: >> >> On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote: >> >>> >>> >>> Templin, Fred L wrote: >>> >>>> Yes; I was aware of this. But, what I want to get to is >>>> setting the tunnel MTU to infinity. >>> >>> >>> Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. >>> >>> I agree. >> >> >> Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. >> >> - Jared >> > > > ICMP is just not the way it is ever going to work. I wish you luck in getting your host IP stacks to work properly without ICMP, especially as you deploy IPv6. - Jared From phillipa at cs.toronto.edu Mon Oct 29 20:51:02 2012 From: phillipa at cs.toronto.edu (Phillipa Gill) Date: Mon, 29 Oct 2012 16:51:02 -0400 Subject: Routing Policy Survey Message-ID: <508EEC36.1060300@cs.toronto.edu> Hi all, To follow up on my presentation at NANOG56 last week: http://www.cs.toronto.edu/~phillipa/papers/PGill_NANOG56_Web.pdf where I reported on the results of preliminary survey we ran to understand the routing policies you use in your networks, we created a new survey to better understand some of the observations made in the first one: http://bit.ly/routingsurvey As I said on Monday, research on interdomain routing could really benefit from a better understanding of the routing policies and we need your help! If you operate a network, we want to hear from you. Answer as many, or as few, questions as you like. The raw survey results will be kept anonymous and summary results communicated to the community. Thanks again to everyone who talked to me about this at NANOG, and to everyone who filled out the earlier incarnation of this survey. If you have any comments, question, or information to share with us, please be in touch. Thanks, Phillipa Gill, Sharon Goldberg, Michael Schapira From Cameron.Rutis at portlandoregon.gov Mon Oct 29 20:55:19 2012 From: Cameron.Rutis at portlandoregon.gov (Rutis, Cameron) Date: Mon, 29 Oct 2012 13:55:19 -0700 Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <955E521BF6D5DE48A9413310E8C0A14716EFA07631@MAIL1.rose.portland.local> During scans at various times in the past (and depending on throttling and settings of that scan) we've seen: 1) small remote site firewalls doing site to site vpns drop a small number of packets 2) locally installed remote control service popup a 'user has been disconnected' error on PCs when port scanned 3) some devices send alerts like 'Unauthorized attempt to gain access' when their SNMP ports are hit with non-standard community strings 4) logging on some devices that causes concern for the admin of that device ("Is someone hacking my device?") 5) out of date/non-patched (yet critical) applications and/or web servers crashing/locking up (this occurred on specific nessus scans, not a generic port/snmp scan) 6) large stacks of 3750s (six or more members) have issues around CPU during certain SNMP commands (I want to say some sort of getbulk type of command) The first four were pretty minor although #3 could generate a lot of calls to the support center. #5 was a big deal due to the nature of the application. #6 was impactful because we dropped routing neighbors for about 10 seconds but this was a couple of years ago so may have been an old IOS bug. -----Original Message----- From: Pedersen, Sean [mailto:Sean.Pedersen at usairways.com] Sent: Monday, October 29, 2012 12:11 PM To: nanog at nanog.org Subject: Network scan tool/appliance horror stories We're evaluating several tools at the moment, and one vendor wants to dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the works. I was curious if anyone had any particularly gruesome horror stories of scanning tools run amok. From Fred.L.Templin at boeing.com Mon Oct 29 21:03:14 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 29 Oct 2012 14:03:14 -0700 Subject: IP tunnel MTU In-Reply-To: <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <508EEA86.2020007@ttec.com> <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> Message-ID: > I wish you luck in getting your host IP stacks to work properly without > ICMP, especially as you deploy IPv6. >From what I've heard, ICMPv6 is already being filtered, including PTBs. I have also heard that IPv6 fragments are also being dropped unconditionally along some paths. So, if neither ICMPv6 PTB nor IPv6 fragmentation works then the tunnel endpoints have to take matters into their own hands. That's where SEAL comes in. Thanks - Fred fred.l.templin at boeing.com > - Jared From jmaimon at ttec.com Mon Oct 29 21:04:53 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 29 Oct 2012 17:04:53 -0400 Subject: IP tunnel MTU In-Reply-To: <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <508EEA86.2020007@ttec.com> <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> Message-ID: <508EEF75.1030006@ttec.com> Jared Mauch wrote: > >> ICMP is just not the way it is ever going to work. > > I wish you luck in getting your host IP stacks to work properly without ICMP, especially as you deploy IPv6. > > - Jared Precisely the state we are in. Looking for luck. Joe From bmanning at vacation.karoshi.com Mon Oct 29 21:15:28 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Oct 2012 21:15:28 +0000 Subject: IP tunnel MTU In-Reply-To: <508EEAB8.9080209@ttec.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <20121029202832.GA1970@vacation.karoshi.com.> <508EEAB8.9080209@ttec.com> Message-ID: <20121029211528.GB1970@vacation.karoshi.com.> On Mon, Oct 29, 2012 at 04:44:40PM -0400, Joe Maimon wrote: > > > bmanning at vacation.karoshi.com wrote: > >On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote: > >> > >> > >>Templin, Fred L wrote: > >> > >>>Yes; I was aware of this. But, what I want to get to is > >>>setting the tunnel MTU to infinity. > >> > >> > >>Essentially, its time the network matured to the point where > >>inter-networking actually works (again), seamlessly. > >> > >>I agree. > >> > >>Joe > > > > you mean its safe to turn off the VPNs? > > > >/bill > > > > > > Quite the reverse. > > Joe so its tunnels all the way down... maybe we should just go back to a circuit oriented network, eh? /bill From sylvie at newnog.org Mon Oct 29 22:27:33 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 29 Oct 2012 18:27:33 -0400 Subject: [NANOG-announce] 2012 Communications Committee Appointments Announcement Message-ID: *Greetings NANOG Colleagues, * * The Board has completed the Communications Committee selection process for 2012. We are pleased to announce the two-year term appointment of Larry Blunk, Colin Corbett and Andrew Koch to the Communications Committee. We also want to thank and recognize Randy Epstein for serving four years on the CC and for his leadership as Chair this past year. In the coming weeks, the new Development Committee will hold its first meeting and select a Chair and a Vice-Chair. On behalf of the Board, * Sylvie -- Sylvie LaPerriere Chair, NANOG Board of Directors www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jmaimon at ttec.com Mon Oct 29 22:45:44 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 29 Oct 2012 18:45:44 -0400 Subject: IP tunnel MTU In-Reply-To: <20121029211528.GB1970@vacation.karoshi.com.> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <20121029202832.GA1970@vacation.karoshi.com.> <508EEAB8.9080209@ttec.com> <20121029211528.GB1970@vacation.karoshi.com.> Message-ID: <508F0718.5040209@ttec.com> bmanning at vacation.karoshi.com wrote: >>> >>> you mean its safe to turn off the VPNs? >>> >>> /bill >>> >>> >> >> Quite the reverse. >> >> Joe > > so its tunnels all the way down... maybe we should just go back to > a circuit oriented network, eh? > > /bill > > Its not safe to turn on VPNs. Joe From bill at herrin.us Mon Oct 29 22:47:29 2012 From: bill at herrin.us (William Herrin) Date: Mon, 29 Oct 2012 18:47:29 -0400 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: On Mon, Oct 29, 2012 at 10:54 AM, Ray Soucy wrote: > The core issue here is TCP MSS. PMTUD is a dynamic process for > adjusting MSS, but requires that ICMP be permitted to negotiate the > connection. The realistic alternative, in a world that filters all > ICMP traffic, is to manually rewrite the MSS. In IOS this can be > achieved via "ip tcp adjust-mss" and on Linux-based systems, netfilter > can be used to adjust MSS for example. Longer term, the ideal solution would be a replacement algorithm that allows TCP to adjust its MSS with or without negative acknowledgement from intermediate routers. The ICMP-didn't-get-there problem is only going to get worse and things like private IPs on routers and encapsulation mechanisms where the intermediate router isn't dealing with an IP packet directly are as much at fault these days as foolish firewall admins. Perhaps my understanding of end-to-end is flawed, but I suspect it means that an endpoint shouldn't depend on direct communication with an intermediate system for its successful communication with another endpoint. Maybe something as simple as clearing the don't fragment flag and adding a TCP option to report receipt of a fragmented packet along with the fragment sizes back to the sender so he can adjust his mss to avoid fragmentation. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Fred.L.Templin at boeing.com Mon Oct 29 23:02:33 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 29 Oct 2012 16:02:33 -0700 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: Hi Bill, > Maybe something as simple as clearing the don't fragment flag and > adding a TCP option to report receipt of a fragmented packet along > with the fragment sizes back to the sender so he can adjust his mss to > avoid fragmentation. That is in fact what SEAL is doing, but there is no guarantee that the size of the largest fragment is going to be an accurate reflection of the true path MTU. RFC1812 made sure of that when it more or less gave IPv4 routers permission to fragment packets pretty much any way they want. Thanks - Fred fred.l.templin at boeing.com From rekoil at semihuman.com Mon Oct 29 23:40:22 2012 From: rekoil at semihuman.com (Chris Woodfield) Date: Mon, 29 Oct 2012 16:40:22 -0700 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> Message-ID: <6051FB67-E86D-41EB-A4EC-1B5E3EC27E5F@semihuman.com> True, but it could be used as an alternative PMTUD algorithm - raise the segment size and wait for the "I got this as fragments" option to show up... Of course, this only works for IPv4. IPv6 users are SOL if something in the middle is dropping ICMPv6. -C On Oct 29, 2012, at 4:02 PM, Templin, Fred L wrote: > Hi Bill, > >> Maybe something as simple as clearing the don't fragment flag and >> adding a TCP option to report receipt of a fragmented packet along >> with the fragment sizes back to the sender so he can adjust his mss to >> avoid fragmentation. > > That is in fact what SEAL is doing, but there is no guarantee > that the size of the largest fragment is going to be an accurate > reflection of the true path MTU. RFC1812 made sure of that when > it more or less gave IPv4 routers permission to fragment packets > pretty much any way they want. > > Thanks - Fred > fred.l.templin at boeing.com > From nicholas.hatch at gmail.com Tue Oct 30 00:14:56 2012 From: nicholas.hatch at gmail.com (nick hatch) Date: Mon, 29 Oct 2012 19:14:56 -0500 Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: On Mon, Oct 29, 2012 at 2:10 PM, Pedersen, Sean wrote: > I was curious if anyone had any particularly gruesome horror stories of > scanning tools run amok. > A particular model of ShoreTel voice switches I used to administer (running VxWorks, IIRC) would reliably lock up hard when hit with nmap's OS/service detection on a particular port. Required pulling the plug to restore service. The truly odd thing was that it didn't seem like a resource exhaustion issue, it could be triggered with a single well-crafted probe or two. After several long nights of painful troubleshooting with their level III support, we came to the conclusion that if it hurts, you probably shouldn't do it, and mitigating ACLs were put in place. -n From jeroen at mompl.net Tue Oct 30 00:54:53 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 29 Oct 2012 17:54:53 -0700 Subject: IPv4 address length technical design In-Reply-To: <506C6D69.5080506@dds.nl> References: <3BDE1550-5D07-46E9-A667-33C416E74FC6@ctcampbell.com> <925f3087-c201-4e51-8931-932e0fd8e177@email.android.com> <506C6D69.5080506@dds.nl> Message-ID: <508F255D.60400@mompl.net> On 10/03/2012 09:52 AM, Seth Mos wrote: > Op 3-10-2012 18:33, Kevin Broderick schreef: >> I'll add that in the mid-90's, in a University Of Washington lecture >> hall, Vint Cerf expressed some regret over going with 32 bits. Chuckle >> worthy and at the time, and a fond memory >> - K > > "Pick a number between this and that." It's the 80's and you can still > count the computers in the world. :) > Oops... And that was not quite what Mr Cerf meant to do. I finally got around to finding a reply Vint Cerf wrote to a thread I started a year or two ago. The url is http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html and quoted below in full for future prosperity. This gives a great behind the scenes view and a clear idea on the thought processes involved and why things evolved the way they did. Interestingly ipv6 is 128 bits, and I personally would have loved to see variable length address structures being implemented, alas. Maybe when ipv6 is in need of replacement... * Begin quote * Hi, Vint Cerf kindly sent through some more explanation. Regards, Mark. Begin forwarded message: Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf To: Mark Smith Cc: Andrew Gray <3356 at blargh.com>, NANOG List Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint * end quote * -- Earthquake Magnitude: 4.7 Date: Monday, October 29, 2012 23:51:42 UTC Location: Flores region, Indonesia Latitude: -8.1762; Longitude: 123.4122 Depth: 19.60 km From mjo at dojo.mi.org Tue Oct 30 00:44:01 2012 From: mjo at dojo.mi.org (Mike O'Connor) Date: Mon, 29 Oct 2012 20:44:01 -0400 Subject: the little ssh that (sometimes) couldn't In-Reply-To: <20121029170743.GB2527@vacation.karoshi.com.> References: <20121029170743.GB2527@vacation.karoshi.com.> Message-ID: <20121030004401.GB19939@dojo.mi.org> : :corruption! : : :http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html I ran into a similar issue with a customer just a few days ago! The customer's theory was that there was something badly wrong with their dorky gateway/switch (which we sold and support ). ssh was timing out, with a SSH2_MSG_KEX_DH_GEX_GROUP hang/failure during the ssh protocol exchange. Based on that, some wireshark captures, and and stray Google droppings, I advised them to ratchet down the MTU to make things work. Through bisectional MTU settings and pinging, we arrived at an MTU of 850. And I initially started cursing at the switch (because that helps move packets, really :) ). Turns out -- the ssh server in question was running RHEL 5.x Linux, and that was the key. Even though "ip route show cache" looked sane, "ip route flush cache" (which I had them run, just on a lark) made the problem go away. So it probably wasn't my switch (unless it had done something untoward in the distant past that induced some weird Linux stack bug). I'm mostly posting this because I was wondering if anyone else had run into an MTU of 850 before. Is that a "magic number" that rings any bells (or perhaps has seen the Linux route cache behavior I did). -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "It is now the age of now." -Non Campus Mentis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Tue Oct 30 04:07:19 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 30 Oct 2012 13:07:19 +0900 Subject: IP tunnel MTU In-Reply-To: References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <508EDD31.4030100@ttec.com> <508EEA86.2020007@ttec.com> <5BE17D85-A7A1-431B-84F2-43E61EB636C8@puck.nether.net> Message-ID: <508F5277.2040408@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> I wish you luck in getting your host IP stacks to work properly without >> ICMP, especially as you deploy IPv6. >>From what I've heard, ICMPv6 is already being filtered, including > PTBs. As v6 PTBs are specified to be generated even against multicast packets, it is of course that they are dropped to prevent ICMP implosions. But, it is a very serious problem of not only tunnels but entire IPv6. That is, if PMTUD is unavailable, IPv6 hosts are prohibited to send packets larger than 1280B. Then, ignoring the prohibition, tunnel end points may send packets a little larger than 1280B, which means physical link MTU of 1500B or a little smaller than that is enough for nested tunnels. Thus, no new tunneling protocol is necessary. The harder part of the job is to disable PMTUD on all the IPv6 implementations. > I have also heard that IPv6 fragments are also being dropped > unconditionally along some paths. Again, it is not a problem of tunnels only. If that is the operational reality, specifications on fragmentation must be dropped from IPv6 specification. Masataka Ohta From malayter at gmail.com Tue Oct 30 05:04:21 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 30 Oct 2012 00:04:21 -0500 Subject: Network scan tool/appliance horror stories In-Reply-To: <955E521BF6D5DE48A9413310E8C0A14716EFA07631@MAIL1.rose.portland.local> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> <955E521BF6D5DE48A9413310E8C0A14716EFA07631@MAIL1.rose.portland.local> Message-ID: <21314D4E-1D49-4FB4-9DA6-E8FA9C740674@gmail.com> On Oct 29, 2012, at 3:55 PM, "Rutis, Cameron" > > 6) large stacks of 3750s (six or more members) have issues around CPU during certain SNMP commands (I want to say some sort of getbulk type of command) > > The first four were pretty minor although #3 could generate a lot of calls to the support center. #5 was a big deal due to the nature of the application. #6 was impactful because we dropped routing neighbors for about 10 seconds but this was a couple of years ago so may have been an old IOS bug. Saw the same. All of our 3750 stacks (which are small) committed suicide during a trial of Foglight. We had discovery timings turned way down, but it still caused a reload on a mix of the last supposedly really stable releases of 12.x. Not confidence inspiring. TAC was useless and suggested a v15 upgrade despite no known fix. The proposed v15 upgrade sent our lab boxes into continuous reload unless you broke the stack and manually wiped each switch. Oh, and port 28 was invisible on each switch after upgrade, and Gi2/0/28 would throw a syntax error. Wait for new releases, lather, rinse, repeat. Total time to resolution in production was several man-weeks on our side, and a few months calendar time, all because the discovery scan revealed how great a "software company" Cisco has become. From andreas at naund.org Tue Oct 30 05:47:12 2012 From: andreas at naund.org (Andreas Ott) Date: Mon, 29 Oct 2012 22:47:12 -0700 Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com>; from Sean.Pedersen@usairways.com on Mon, Oct 29, 2012 at 12:10:40PM -0700 References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: <20121029224712.M10492@naund.org> On Mon, Oct 29, 2012 at 12:10:40PM -0700, Pedersen, Sean wrote: > We're evaluating several tools at the moment, and one vendor wants to > dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, > the works. I was curious if anyone had any particularly gruesome horror > stories of scanning tools run amok. Check your netmask on the to-be-discovered network and what the rate of discovery is. I have seen internal systems attempt to scan and discover nodes in a /16 and promptly set off a flood of alarms on all PDUs (6 per rack) and plenty of other devices that thought they are being attacked. -andreas From kauto at huopio.fi Tue Oct 30 07:46:52 2012 From: kauto at huopio.fi (Kauto Huopio) Date: Tue, 30 Oct 2012 09:46:52 +0200 Subject: Flood affecting US east coast communication facilities? Message-ID: Greetings all, Any reports on damage to communications facilities on US east coast? --Kauto -- Kauto Huopio - kauto at huopio.fi (dayjob @ CERT-FI ) From jsw at inconcepts.biz Tue Oct 30 07:55:18 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 30 Oct 2012 03:55:18 -0400 Subject: Flood affecting US east coast communication facilities? In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 3:46 AM, Kauto Huopio wrote: > Any reports on damage to communications facilities on US east coast? Yes. The outages list is a better place to look for this information. https://puck.nether.net/pipermail/outages/2012-October/date.html -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From contact at nullivex.com Tue Oct 30 07:57:47 2012 From: contact at nullivex.com (Bryan Tong) Date: Tue, 30 Oct 2012 01:57:47 -0600 Subject: Flood affecting US east coast communication facilities? In-Reply-To: References: Message-ID: I saw cogent is sending 50k less routes today dunno if that has anything to do with it. On Tue, Oct 30, 2012 at 1:55 AM, Jeff Wheeler wrote: > On Tue, Oct 30, 2012 at 3:46 AM, Kauto Huopio wrote: >> Any reports on damage to communications facilities on US east coast? > > Yes. The outages list is a better place to look for this information. > > https://puck.nether.net/pipermail/outages/2012-October/date.html > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From sarah.nataf at gmail.com Tue Oct 30 08:21:16 2012 From: sarah.nataf at gmail.com (Sarah Nataf) Date: Tue, 30 Oct 2012 09:21:16 +0100 Subject: Belpak / Beltelecom contact to address a BGP hijacking issue? In-Reply-To: References: Message-ID: Hi, On Mon, Oct 29, 2012 at 7:03 PM, Anurag Bhatia wrote: > Seems like they are not advertising it anymore. AS6697 has transit from > Level3 and peering/transit from HE. Both of them show path to AS3215 for > that prefix now. Yes, seems that the annoucement stopped yesterday, after 5 days: Origin AS First Seen Last Seen AS3215 2012-10-28 17:32:51 UTC 2012-10-30 07:00:20 UTC AS6697 2012-10-24 09:28:20 UTC 2012-10-29 12:18:10 UTC AS5396 2012-10-24 09:17:58 UTC 2012-10-24 09:17:58 UTC Anyway, as we couldn't reach anyone from Belpak, not sure how the issue was solved. So I think we'll let the 2.2.2.0/24 a few days more (usually only the 2.2.0.0/16 is advertised by AS3215... but the 2.2.2.0/24 prefix is so often subject to hijacking that we might permanently add this /24 as well). -- sarah From viraviralh at gmail.com Tue Oct 30 08:41:32 2012 From: viraviralh at gmail.com (Viral Vira) Date: Tue, 30 Oct 2012 14:11:32 +0530 Subject: Flood affecting US east coast communication facilities? In-Reply-To: References: Message-ID: I think XO circuits are also affected due to "Sandy" -Thanks, Viral On 30 October 2012 13:16, Kauto Huopio wrote: > Greetings all, > > Any reports on damage to communications facilities on US east coast? > > --Kauto > > -- > Kauto Huopio - kauto at huopio.fi > (dayjob @ CERT-FI ) > > From tim at pelican.org Tue Oct 30 10:01:50 2012 From: tim at pelican.org (Tim Franklin) Date: Tue, 30 Oct 2012 10:01:50 -0000 (GMT) Subject: IP tunnel MTU In-Reply-To: Message-ID: >> Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. > > Wait till you get started on "fixing" the "security" consultants. Ack. I've yet to come across a *device* that doesn't deal properly with "packet too big". Lots (and lots and lots) of "security" people, one or two applications, but no devices. Regards, Tim. From sander at steffann.nl Tue Oct 30 10:19:39 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 30 Oct 2012 11:19:39 +0100 Subject: IP tunnel MTU In-Reply-To: References: Message-ID: <40ADDAAF-102B-44A8-90B1-BA429FA1196D@steffann.nl> Hi, >>> Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. >> >> Wait till you get started on "fixing" the "security" consultants. > > Ack. I've yet to come across a *device* that doesn't deal properly with "packet too big". Lots (and lots and lots) of "security" people, one or two applications, but no devices. I know of one: Juniper SSG and SRX boxes used to block IPv6 ICMP errors when the screening option 'big ICMP packets' was enabled because it blocked all (v4 and v6) ICMP packets bigger than 1024 bytes and IPv6 ICMP errors are often 1280 bytes. I don't know if that has been fixed yet. - Sander From jeroen at unfix.org Tue Oct 30 10:23:21 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 30 Oct 2012 11:23:21 +0100 Subject: IP tunnel MTU In-Reply-To: <40ADDAAF-102B-44A8-90B1-BA429FA1196D@steffann.nl> References: <40ADDAAF-102B-44A8-90B1-BA429FA1196D@steffann.nl> Message-ID: <508FAA99.6030600@unfix.org> On 2012-10-30 11:19, Sander Steffann wrote: > Hi, > >>>> Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. >>> >>> Wait till you get started on "fixing" the "security" consultants. >> >> Ack. I've yet to come across a *device* that doesn't deal properly with "packet too big". Lots (and lots and lots) of "security" people, one or two applications, but no devices. > > > I know of one: Juniper SSG and SRX boxes used to block IPv6 ICMP errors when the screening option 'big ICMP packets' was enabled because it blocked all (v4 and v6) ICMP packets bigger than 1024 bytes and IPv6 ICMP errors are often 1280 bytes. I don't know if that has been fixed yet. I do not see them "fixing" that either, if one misconfigures a host to filter big ICMP packets, you get exactly that, it will filter those packets. In the same way as folks misconfiguring hosts to drop ICMP in general etc. One cannot solve stupid people as they will do stupid things. Greets, Jeroen From Fred.L.Templin at boeing.com Tue Oct 30 14:10:55 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 30 Oct 2012 07:10:55 -0700 Subject: IP tunnel MTU In-Reply-To: <6051FB67-E86D-41EB-A4EC-1B5E3EC27E5F@semihuman.com> References: <83452cbbe5c3c5439212c8a56346b283@mail.dessus.com> <20121022041852.401AC2A18950@drugs.dv.isc.org> <20121022163626.GA50527@dyn.com> <6102075A-2C61-4C84-AB07-C34DAFB2FE31@arbor.net> <6051FB67-E86D-41EB-A4EC-1B5E3EC27E5F@semihuman.com> Message-ID: Hi Chris, > -----Original Message----- > From: Chris Woodfield [mailto:rekoil at semihuman.com] > Sent: Monday, October 29, 2012 4:40 PM > To: Templin, Fred L > Cc: William Herrin; Ray Soucy; NANOG list > Subject: Re: IP tunnel MTU > > True, but it could be used as an alternative PMTUD algorithm - raise the > segment size and wait for the "I got this as fragments" option to show > up... Yes; it is a very attractive option on the surface. Steve Deering called it "Report Fragmentation (RF)" when he first proposed it back in 1988, but it didn't gain sufficient traction and what we got instead was RFC1191. As I mentioned, SEAL does this already but in a "best effort" fashion. SEAL will work over paths that don't conform well to the RF model, but will derive some useful benefit from paths that do. > Of course, this only works for IPv4. IPv6 users are SOL if something in > the middle is dropping ICMPv6. Sad, but true. Thanks - Fred fred.l.templin at boeing.com > -C > > On Oct 29, 2012, at 4:02 PM, Templin, Fred L wrote: > > > Hi Bill, > > > >> Maybe something as simple as clearing the don't fragment flag and > >> adding a TCP option to report receipt of a fragmented packet along > >> with the fragment sizes back to the sender so he can adjust his mss to > >> avoid fragmentation. > > > > That is in fact what SEAL is doing, but there is no guarantee > > that the size of the largest fragment is going to be an accurate > > reflection of the true path MTU. RFC1812 made sure of that when > > it more or less gave IPv4 routers permission to fragment packets > > pretty much any way they want. > > > > Thanks - Fred > > fred.l.templin at boeing.com > > From carlosm3011 at gmail.com Tue Oct 30 14:33:48 2012 From: carlosm3011 at gmail.com (Carlos M. martinez) Date: Tue, 30 Oct 2012 12:33:48 -0200 Subject: IPv6 only streaming video In-Reply-To: <262CA69F-EC5C-43A0-93AD-770A44B23D80@huawei.com> References: <262CA69F-EC5C-43A0-93AD-770A44B23D80@huawei.com> Message-ID: <508FE54C.5060202@gmail.com> Hello, Due to popular demand ( :=)) ), we are currently offering the streaming of the LACNIC / LACNOG event over an IP6-only channel. Take a look at http://www2.lacnic.net/sp/eventos/lacnicxviii/stream6.html The webpage will load over IPv4 but the video is IPv6-only regards ~Carlos On 7/25/12 2:11 PM, Tina TSOU wrote: > http://video.v6.labs.lacnic.net/jw/ > Server can not be found since yesterday. Has the URL been changed? > > Tina > 408-859-4996 > From BEJones at semprautilities.com Tue Oct 30 15:18:18 2012 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 30 Oct 2012 08:18:18 -0700 Subject: Network scan tool/appliance horror stories In-Reply-To: <20121029194646.GD13937@dan.olp.net> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> <20121029194646.GD13937@dan.olp.net> Message-ID: I can share with you several stories personnel (both IT or vendors), who have scanned Electric Utility environments with or without permission; and hence caused multiple failures - including electro-mechanical systems and related applications. Utilities typically utilize many industrial controllers - some of which many IT personnel have no knowledge, and some are not robust enough to weather the storm. 1. Know your environment. 2. Know your tools. 3. Communicate. -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Monday, October 29, 2012 12:47 PM To: Pedersen, Sean Cc: nanog at nanog.org Subject: Re: Network scan tool/appliance horror stories On 10/29/12?12:10?-0700, Pedersen, Sean wrote: >We're evaluating several tools at the moment, and one vendor wants to >dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, >the works. I was curious if anyone had any particularly gruesome horror >stories of scanning tools run amok. http://www.tulsaworld.com/news/article.aspx?subjectid=334&articleid=20121002_11_A1_CUTLIN325691 A > layer 7 failure. Make sure all members of your organization are aware of your plans. -- Dan White From sliplever at gmail.com Tue Oct 30 15:22:24 2012 From: sliplever at gmail.com (Dan Snyder) Date: Tue, 30 Oct 2012 11:22:24 -0400 Subject: Network scan tool/appliance horror stories In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: We have had ncircle scans unexpectedly crash alcatel-lucent omni-switches. On Mon, Oct 29, 2012 at 3:10 PM, Pedersen, Sean wrote: > We're evaluating several tools at the moment, and one vendor wants to dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the works. I was curious if anyone had any particularly gruesome horror stories of scanning tools run amok. From chuckchurch at gmail.com Tue Oct 30 17:22:44 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 30 Oct 2012 13:22:44 -0400 Subject: Network scan tool/appliance horror stories In-Reply-To: References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> <20121029194646.GD13937@dan.olp.net> Message-ID: <002501cdb6c3$303a2f90$90ae8eb0$@gmail.com> Network scan tools are a great way to verify what important protocols you left out of your control plane policing non-default policies. Had a scanner totally clog up our 6500 core router DHCP relay (ip helper) function once. Uggghhh, security people.... Chuck From BEJones at semprautilities.com Tue Oct 30 17:57:02 2012 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 30 Oct 2012 10:57:02 -0700 Subject: Network scan tool/appliance horror stories In-Reply-To: <002501cdb6c3$303a2f90$90ae8eb0$@gmail.com> References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> <20121029194646.GD13937@dan.olp.net> <002501cdb6c3$303a2f90$90ae8eb0$@gmail.com> Message-ID: Speaking of scan tools, does anyone have recommendations for tools to do baseline configurations on Windows systems? Looking for pre-change configuration baseline and post change configuration baseline - to identify differences implemented by the change? Thanks. -----Original Message----- From: Chuck Church [mailto:chuckchurch at gmail.com] Sent: Tuesday, October 30, 2012 10:23 AM To: nanog at nanog.org Subject: RE: Network scan tool/appliance horror stories Network scan tools are a great way to verify what important protocols you left out of your control plane policing non-default policies. Had a scanner totally clog up our 6500 core router DHCP relay (ip helper) function once. Uggghhh, security people.... Chuck From lists at mtin.net Tue Oct 30 21:00:47 2012 From: lists at mtin.net (Justin Wilson) Date: Tue, 30 Oct 2012 17:00:47 -0400 Subject: New York Crews? Message-ID: Anyone know of lists, contacts, etc. for companies looking for I.T. Folks for help with cleanup and such on the eastern seaboard? I am guessing there will be a demand for anyone from cable pullers to Engineers. I have some free time on my hands and would gladly take a cut in pay to go out and work with the cleanup. I can terminate cables, climb towers, etc. I am sure I am not the only underemployed I.T. Guy who could spend a week or two helping a data center, or other entity. Just wondering if anyone knew of any resources, groups, contacts. Thanks, Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter From rali.ahmed at gmail.com Tue Oct 30 23:18:39 2012 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Wed, 31 Oct 2012 02:18:39 +0300 Subject: Twitter Issue Message-ID: Hi All Was there is any global issue in Twitter.com here is saudi arabia we were not able to access twitter.com from 3:30 to 06:30 GMT any idea ? *Rashed Alwarrag * From morrowc.lists at gmail.com Wed Oct 31 02:47:02 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 30 Oct 2012 22:47:02 -0400 Subject: Twitter Issue In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 7:18 PM, Rashed Alwarrag wrote: > Hi All > > Was there is any global issue in Twitter.com here is saudi arabia we were > not able to access twitter.com from 3:30 to 06:30 GMT any idea ? does the saudi telecom ministry (or like agency) limit access to things perhaps? From ag4ve.us at gmail.com Wed Oct 31 15:39:35 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 31 Oct 2012 15:39:35 +0000 Subject: New York Crews? In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 9:00 PM, Justin Wilson wrote: > Just wondering if anyone knew of any resources, groups, contacts. > I would also be interested in this (figured I'd comment in case someone wanted to keep this off list) From serajul.hossain at gree.net Wed Oct 31 16:02:53 2012 From: serajul.hossain at gree.net (Serajul Hossain) Date: Wed, 31 Oct 2012 12:02:53 -0400 Subject: altdb contact Message-ID: Dear Nanog member, I would like to know if there is anyone on this mailing list who is volunteering to help manage altdb.net It seems like no one is actually responding to db-admin at altdb.net We need to update information on our new address block that was originally owned by a different company. Regards, Serajul From jeffshultz at wvi.com Wed Oct 31 16:19:49 2012 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 31 Oct 2012 09:19:49 -0700 Subject: 75th Broad up/down? Message-ID: <50914FA5.9080901@wvi.com> An online magazine I work with is, we believe, hosted at 75 Broad or 111 8th. It dropped out Monday night, right after they announced that the diesel pumps had fried due to flooding at 75 Broad, came back up early Tuesday morning, and then died again this morning. IP address is in 74.63.44.0/24 block (which may be part of a larger block). Pinging 74.63.44.255 gets me replies from 208.122.44.210 only. Anyone know the current status of these facilities? I've got an e-mail in to noc at internap but haven't heard back - and if they have a facility down they're probably too busy to reply to a single web hosting customer. I have seen the report from earlier this morning indicating that 111 8th had an issue that's been fixed - but the Internap NOC line (877.843.4662) still indicates that NYM008 is having a power outage. Thanks! -- Jeff Shultz From virendra.rode at gmail.com Wed Oct 31 17:50:48 2012 From: virendra.rode at gmail.com (virendra rode) Date: Wed, 31 Oct 2012 10:50:48 -0700 Subject: 75th Broad up/down? In-Reply-To: <50914FA5.9080901@wvi.com> References: <50914FA5.9080901@wvi.com> Message-ID: <509164F8.8050201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/31/2012 09:19 AM, Jeff Shultz wrote: > An online magazine I work with is, we believe, hosted at 75 Broad > or 111 8th. It dropped out Monday night, right after they announced > that the diesel pumps had fried due to flooding at 75 Broad, came > back up early Tuesday morning, and then died again this morning. > > IP address is in 74.63.44.0/24 block (which may be part of a larger > block). > > Pinging 74.63.44.255 gets me replies from 208.122.44.210 only. > > Anyone know the current status of these facilities? I've got an > e-mail in to noc at internap but haven't heard back - and if they have > a facility down they're probably too busy to reply to a single web > hosting customer. > > I have seen the report from earlier this morning indicating that > 111 8th had an issue that's been fixed - but the Internap NOC line > (877.843.4662) still indicates that NYM008 is having a power > outage. > > Thanks! > - ---------------------- http://tracker.outages.org/reports/view/68 and more update on the list. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCRZPgACgkQ3HuimOHfh+HKKgEAhF3Iwx8/LOqAM49MmOsI6uwZ fdHcLpOFMBHFzYyFRoUBAIH91cZKrmzooK/Akhl4IixNEw4fu6P/Yq4D5W0nrcvv =1QUU -----END PGP SIGNATURE----- From wingar at team-metro.net Tue Oct 30 07:53:24 2012 From: wingar at team-metro.net (Emily Ozols) Date: Tue, 30 Oct 2012 18:53:24 +1100 Subject: Flood affecting US east coast communication facilities? In-Reply-To: References: Message-ID: Hi Kauto, Internaps LGA11 DC in NYC was knocked out recently by Sandy. Here's the official statement: "Please be advised that Internap's LGA11 facility is experiencing significant flooding in the sub-basement of the 75 Broad Street building as a result of Hurricane Sandy. The flooding has submerged and destroyed the site's diesel pumps and is preventing fuel from being pumped to the generators on the mezzanine level. The available fuel reserves on the mezzanine level are estimated to support customer loads for approximately 5-7 hours. Once this fuel supply has been exhausted the generator will no longer be able to sustain operation and critical customer power loads will be lost." The email was sent a while ago and by now the diesel would have run out. Internap shut down server for customers those that they were contractually obligated to. Currently it seems that the AWS stuff is still up and same for Rackspace. However there have been reports of the US East submarine cables going dark. On Tue, Oct 30, 2012 at 6:46 PM, Kauto Huopio wrote: > Greetings all, > > Any reports on damage to communications facilities on US east coast? > > --Kauto > > -- > Kauto Huopio - kauto at huopio.fi > (dayjob @ CERT-FI ) > > -- ~Em From virendra.rode at gmail.com Wed Oct 31 18:17:17 2012 From: virendra.rode at gmail.com (virendra rode) Date: Wed, 31 Oct 2012 11:17:17 -0700 Subject: New York Crews? In-Reply-To: References: Message-ID: <50916B2D.7030305@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 10/30/2012 02:00 PM, Justin Wilson wrote: > Anyone know of lists, contacts, etc. for companies looking for > I.T. Folks for help with cleanup and such on the eastern seaboard? > I am guessing there will be a demand for anyone from cable pullers > to Engineers. I have some free time on my hands and would gladly > take a cut in pay to go out and work with the cleanup. I can > terminate cables, climb towers, etc. I am sure I am not the only > underemployed I.T. Guy who could spend a week or two helping a > data center, or other entity. > > Just wondering if anyone knew of any resources, groups, contacts. > > Thanks, Justin > > -- Justin Wilson Aol & Yahoo IM: j2sw > http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? > Follow me on Twitter - ----------------------- If people interested in such effort feel free to drop me a note w/ your location, contact and what are you willing to help w/. I can put a list and plot it on tracker so people reach you if need be. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCRay0ACgkQ3HuimOHfh+G3jQD+NacDHePtULlPQBw4UBRwkl0e DG9igmrlbLR7/6X/kRoA/RNWKwyBDrSJ8BtaB2UcF6MF247wgNCKZZLB9rLTdwAc =IShy -----END PGP SIGNATURE----- From alex at corp.nac.net Wed Oct 31 18:23:14 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 31 Oct 2012 14:23:14 -0400 Subject: Flood affecting US east coast communication facilities? In-Reply-To: References: Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B1C2@EXCHMBX.hq.nac.net> If anyone is in need of emergency connectivity, VM's, colo, showers, whatever, please contact me. All of our offices in Northern NJ are accessible and online and can support any sort of emergency need. -----Original Message----- From: Emily Ozols [mailto:wingar at team-metro.net] Sent: Tuesday, October 30, 2012 3:53 AM To: nanog at nanog.org Subject: Re: Flood affecting US east coast communication facilities? Hi Kauto, Internaps LGA11 DC in NYC was knocked out recently by Sandy. Here's the official statement: "Please be advised that Internap's LGA11 facility is experiencing significant flooding in the sub-basement of the 75 Broad Street building as a result of Hurricane Sandy. The flooding has submerged and destroyed the site's diesel pumps and is preventing fuel from being pumped to the generators on the mezzanine level. The available fuel reserves on the mezzanine level are estimated to support customer loads for approximately 5-7 hours. Once this fuel supply has been exhausted the generator will no longer be able to sustain operation and critical customer power loads will be lost." The email was sent a while ago and by now the diesel would have run out. Internap shut down server for customers those that they were contractually obligated to. Currently it seems that the AWS stuff is still up and same for Rackspace. However there have been reports of the US East submarine cables going dark. On Tue, Oct 30, 2012 at 6:46 PM, Kauto Huopio wrote: > Greetings all, > > Any reports on damage to communications facilities on US east coast? > > --Kauto > > -- > Kauto Huopio - kauto at huopio.fi > (dayjob @ CERT-FI ) > > -- ~Em From anwalam at yahoo.com Wed Oct 31 18:25:23 2012 From: anwalam at yahoo.com (andy lam) Date: Wed, 31 Oct 2012 11:25:23 -0700 (PDT) Subject: NSA and the exchanges Message-ID: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Anyone knows if there's a way to find out how involved NSA monitors 151 front street at Toronto? ?NSA allegedly monitors data centres in the US, but does it have the same influence at a building sitting in its neighbor's soil? There's something on the web like www.ixmaps.ca that tries to piece it together. ?but not sure how helpful the information on there really is? feedback welcome. From deleskie at gmail.com Wed Oct 31 18:37:23 2012 From: deleskie at gmail.com (jim deleskie) Date: Wed, 31 Oct 2012 15:37:23 -0300 Subject: NSA and the exchanges In-Reply-To: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Message-ID: If your talking "the NSA" I doubt anyone would tell you. That being said: it would mean the US gov't breaking Canadian law I suspect. Now in Canada it is quite possible that the Canadian Fed gov't monitors traffic but I would also say no one would tell you because telling you would also be in violation in wiretap laws. Best advice, assume they do and hope they don't. :) -jim On Wed, Oct 31, 2012 at 3:25 PM, andy lam wrote: > Anyone knows if there's a way to find out how involved NSA monitors 151 front street at Toronto? NSA allegedly monitors data centres in the US, but does it have the same influence at a building sitting in its neighbor's soil? > > There's something on the web like www.ixmaps.ca that tries to piece it together. but not sure how helpful the information on there really is? > > > feedback welcome. From jna at retina.net Wed Oct 31 18:37:52 2012 From: jna at retina.net (John Adams) Date: Wed, 31 Oct 2012 11:37:52 -0700 Subject: NSA and the exchanges In-Reply-To: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Message-ID: Allegedly? No, definately. https://www.eff.org/nsa-spying https://www.eff.org/files/filenode/att/presskit/ATT_onepager.pdf -j On Wed, Oct 31, 2012 at 11:25 AM, andy lam wrote: > Anyone knows if there's a way to find out how involved NSA monitors 151 > front street at Toronto? NSA allegedly monitors data centres in the US, > but does it have the same influence at a building sitting in its neighbor's > soil? > > There's something on the web like www.ixmaps.ca that tries to piece it > together. but not sure how helpful the information on there really is? > > > feedback welcome. > From erik.soosalu at calyxinc.com Wed Oct 31 18:53:24 2012 From: erik.soosalu at calyxinc.com (Erik Soosalu) Date: Wed, 31 Oct 2012 14:53:24 -0400 Subject: NSA and the exchanges In-Reply-To: References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Message-ID: <0B224A2FE01CC54C860290D42474BF600570D6B8@exchange.nff.local> I'd assume the NSA and CSIS would be talking as needed. Whether CSIS is actually monitoring in there is another question. I'd assume yes, but have never heard anything to confirm or deny. -----Original Message----- From: jim deleskie [mailto:deleskie at gmail.com] Sent: Wednesday, October 31, 2012 2:37 PM To: andy lam Cc: nanog at nanog.org Subject: Re: NSA and the exchanges If your talking "the NSA" I doubt anyone would tell you. That being said: it would mean the US gov't breaking Canadian law I suspect. Now in Canada it is quite possible that the Canadian Fed gov't monitors traffic but I would also say no one would tell you because telling you would also be in violation in wiretap laws. Best advice, assume they do and hope they don't. :) -jim On Wed, Oct 31, 2012 at 3:25 PM, andy lam wrote: > Anyone knows if there's a way to find out how involved NSA monitors 151 front street at Toronto? NSA allegedly monitors data centres in the US, but does it have the same influence at a building sitting in its neighbor's soil? > > There's something on the web like www.ixmaps.ca that tries to piece it together. but not sure how helpful the information on there really is? > > > feedback welcome. From sethm at rollernet.us Wed Oct 31 18:58:21 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 31 Oct 2012 11:58:21 -0700 Subject: NSA and the exchanges In-Reply-To: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Message-ID: <509174CD.2060300@rollernet.us> On 10/31/12 11:25 AM, andy lam wrote: > Anyone knows if there's a way to find out how involved NSA monitors 151 front street at Toronto? NSA allegedly monitors data centres in the US, but does it have the same influence at a building sitting in its neighbor's soil? > > There's something on the web like www.ixmaps.ca that tries to piece it together. but not sure how helpful the information on there really is? > > > feedback welcome. > No Such Agency. ~Seth From rusty at hodge.com Wed Oct 31 19:14:05 2012 From: rusty at hodge.com (Rusty Hodge) Date: Wed, 31 Oct 2012 12:14:05 -0700 Subject: 75th Broad up/down? In-Reply-To: <50914FA5.9080901@wvi.com> References: <50914FA5.9080901@wvi.com> Message-ID: <331AE255-A771-4859-B1B3-E8811F485BF3@hodge.com> Here's a few notes from Internap which has stuff at 75 Broad and 111 8th: ---- Forwarded Message ---- Hurricane Update: Power Restored at LGA9, 111 8th Ave. Update: We have restored all power to the LGA9 site via generator. Phase 1&2 UPS UPS modules are in bypass and being investigated at this time. We will be moving the UPS units back inline one at a time as they are verified over the coming hours. There is no impact to customer load expected. Phase 3 load is currently on UPS conditioned power supported by generator. All INAP IP service points are operating normally. Our staff is currently working to bring LGA9 Agile customers back up. ---- Forwarded Message ---- At approximately 23:20 local time, the LGA11 facility returned to service via generator power, including critical customers loads. The generators were refuelled and restarted and are currently operating normally, carrying the critical load. Additionally UPS systems have since been brought back online and are now helping to support power onsite. Additional fuel supply is being arranged and there is ample fuel on site at the moment to maintain operation. As noted, power to customer gear has been restored, however building access is still restricted and customers are not yet able to visit the site. ---- Forwarded Message ---- At approximately 05:45 EDT connectivity to Internap's LGA11 datacenter was lost. This loss was caused by 2 other datacenter power failures that provide fiber to LGA11. We are working with the building personnel at both sites to correct the problems. We will provide more updates as information becomes available. ---- Forwarded Message ---- At approximately 23:20 local time, Internap's LGA11 facility returned to service via generator power, including critical customers loads. The generators were refueled and restarted and are currently operating normally, carrying the critical load. Additionally UPS systems have since been brought back online and are now helping to support power onsite. There is ample fuel on site at the moment to maintain operation and there is a scheduled delivery of additional fuel. This will continue until Con Ed restores grid power. Most all servers are not back online and accessible. Please log in and confirm that everything is working as expected in your environment. > An online magazine I work with is, we believe, hosted at 75 Broad or 111 8th. It dropped out Monday night, right after they announced that the diesel pumps had fried due to flooding at 75 Broad, came back up early Tuesday morning, and then died again this morning. > > IP address is in 74.63.44.0/24 block (which may be part of a larger block). > > Pinging 74.63.44.255 gets me replies from 208.122.44.210 only. > > Anyone know the current status of these facilities? I've got an e-mail in to noc at internap but haven't heard back - and if they have a facility down they're probably too busy to reply to a single web hosting customer. > > I have seen the report from earlier this morning indicating that 111 8th had an issue that's been fixed - but the Internap NOC line (877.843.4662) still indicates that NYM008 is having a power outage. > > Thanks! > > -- > Jeff Shultz > > > > From rguerra at privaterra.org Wed Oct 31 19:22:57 2012 From: rguerra at privaterra.org (Robert Guerra) Date: Wed, 31 Oct 2012 15:22:57 -0400 Subject: NSA and the exchanges In-Reply-To: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> Message-ID: Andy, Let me recommend the IXmaps project. It is documenting the very question you are asking :) http://www.ixmaps.ca IXmaps is an interactive tool that enables internet users and researchers to study the route(s) that data packets take across North America, with 'interesting' sites highlighted along the way. It is currently under development. It has been supported by a research grant from the Social Sciences and Humanities Research Council of Canada's Image, Text, Sound and Technology program. IXmaps is affiliated with the New Transparency Project and the Information Policy Research Program at theFaculty of Information, University of Toronto. regards Robert -- Robert Guerra Senior Advisor, Citizen Lab Munk School of Global Affairs, University of Toronto Phone: +1 416-893-0377 Cell: +1 202 905 2081 Twitter: twitter.com/netfreedom Email: robert at citizenlab.org Web: http://citizenlab.org On 2012-10-31, at 2:25 PM, andy lam wrote: > Anyone knows if there's a way to find out how involved NSA monitors 151 front street at Toronto? NSA allegedly monitors data centres in the US, but does it have the same influence at a building sitting in its neighbor's soil? > > There's something on the web like www.ixmaps.ca that tries to piece it together. but not sure how helpful the information on there really is? > > > feedback welcome. From alex at corp.nac.net Wed Oct 31 19:24:50 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 31 Oct 2012 15:24:50 -0400 Subject: NJ impact Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B1DF@EXCHMBX.hq.nac.net> I had to summarize this recently for a news article I was interviewed for, so I figured I forward: -- Of our three datacenters, this is what we saw: Parsippany 1 (OCT) - The worst we saw here was several sub-second power hits. UPS's held without problem, and we did not transfer to generator at all yet. Parsippany 2 (WBR) - Transferred to generator at about 7:55 PM EST Monday as a precautionary measure due to ongoing utility power hits. However, shortly after transfer, utility voltage went to 0 on all phases; around 10p power returned, but abnormally high (seeing about 550 volts on 480 volt bus). We retransferred last night as utility voltage settled down. Cedar Knolls 1 (MMU) - Briefly transferred to generator around 7:10, then back to utility. We then force transferred to generator around 8pm and stayed until this morning. Returned to utility and all systems are normal. We have accommodated many customers (and non-customers) by allowing them to use our conference rooms and some offices, mainly because they lost power at their buildings, lost access to their buildings, or generators ran out of fuel. We literally have card tables setup in hallways and common areas where people sit and use Wifi to conduct business. There has been no service interruption of any sort to any of our datacenter customers, as of this writing. We lost one span of fiber optics between MMU and 165 Halsey, Newark (NWR), network healed in less than 1 second. It was imperceptible. That was early though, Monday afternoon. This has since restored today. We have sales people onsite who are actively taking sales calls, and there is a measurable amount of customers moving equipment into our facilities as I write this. Many are moving equipment from offices with no power and no ETR in sight. We have electricians onsite to help accommodate. The facilities department has been manning all locations around the clock. All sites remain accessible by road. There was never a situation where you could not over the last 48 hours. We have no equipment in 111 8th, so I cannot offer any telemetry there. However, our gear in 60 Hudson St (Tel-X 9th floor) is still online. We saw no interruption at 165 Halsey, except for some very brief utility hits. UPS's held. We are seeing hundreds, if not thousands, of DSL / T1 / T3 / Ethernet customers down - presumably mostly power loss on the CPE. We lost our connection to Covad, presumably they have gear in a building which lost power. These are only just starting to come back. We have seen substantial interruption to the cellular networks; in many cases, ATT Wireless (who NAC uses) is unable to complete a call. In certain areas, there is no signal at all. Where I live, in 07874 (Byram), many roads are impassable and most everyone does not have power. Trees are down everywhere. I heard that a Byram squad car had a tree land on it while responding to a call. Schools are closed, Halloween has been "rescheduled" according to our governor. My cable is down, cable modem is down, POTS service is out - yet I still have xDSL (loop by Verizon, IP by NAC) and I run on that successfully. I am unable to get any ATT cell service at my house (usually at least three bars). I am on generator at my house, consuming about 2 gal/hour (propane), with a little over 500 gallons left. Gasonline is becoming an issue. As I understand, having talked to our oil supplier, there is 0 refinery capacity in NJ at this time. All gasoline is being imported from PA, DE, MD, etc. Most stations don't have power. Ones that do are generally out of gas. If they have gas, they have mile long lines and are rationing. Diesel is unavailable if you had not pre-arranged for it. Widespread power outages remain. I am running on generator at my house (Generac QT048) on a 1000 gallon tank of propane, have been since Monday about 7pm. It is estimated at least 7 to 10 days before power restoration. I have yet to see one JCPL truck anywhere near where I live. That is all I have. This is the road leading to the Byram Police Dept - I took this yesterday morning: https://sphotos-a.xx.fbcdn.net/hphotos-prn1/12696_4311181250657_900557870_n.jpg This is typically what Northern NJ looks like: https://sphotos-a.xx.fbcdn.net/hphotos-ash3/548544_4311185050752_1011136048_n.jpg https://sphotos-b.xx.fbcdn.net/hphotos-ash3/61115_4317167440308_289655722_n.jpg (not the top of the telephone pole hanging from the wires) From hcb at netcases.net Wed Oct 31 19:28:57 2012 From: hcb at netcases.net (Howard C. Berkowitz) Date: Wed, 31 Oct 2012 15:28:57 -0400 Subject: NSA and the exchanges In-Reply-To: <0B224A2FE01CC54C860290D42474BF600570D6B8@exchange.nff.local> References: <1351707923.79506.YahooMailNeo@web122202.mail.ne1.yahoo.com> <0B224A2FE01CC54C860290D42474BF600570D6B8@exchange.nff.local> Message-ID: <50917BF9.6050101@netcases.net> On 10/31/2012 2:53 PM, Erik Soosalu wrote: > I'd assume the NSA and CSIS would be talking as needed. Communications Security Establishment to NSA, but point taken. > > Whether CSIS is actually monitoring in there is another question. I'd > assume yes, but have never heard anything to confirm or deny. > > > -----Original Message----- > From: jim deleskie [mailto:deleskie at gmail.com] > Sent: Wednesday, October 31, 2012 2:37 PM > To: andy lam > Cc: nanog at nanog.org > Subject: Re: NSA and the exchanges > > If your talking "the NSA" I doubt anyone would tell you. That being > said: it would mean the US gov't breaking Canadian law I suspect. Now > in Canada it is quite possible that the Canadian Fed gov't monitors > traffic but I would also say no one would tell you because telling you > would also be in violation in wiretap laws. > > Best advice, assume they do and hope they don't. :) > > -jim > > On Wed, Oct 31, 2012 at 3:25 PM, andy lam wrote: >> Anyone knows if there's a way to find out how involved NSA monitors > 151 front street at Toronto? NSA allegedly monitors data centres in the > US, but does it have the same influence at a building sitting in its > neighbor's soil? >> There's something on the web like www.ixmaps.ca that tries to piece it > together. but not sure how helpful the information on there really is? >> >> feedback welcome. > > > From blair.trosper at updraftnetworks.com Wed Oct 31 21:55:56 2012 From: blair.trosper at updraftnetworks.com (Blair Trosper) Date: Wed, 31 Oct 2012 16:55:56 -0500 Subject: Google burp Message-ID: I guess I'll be the one to ask...what's going on over at Google? Service interruptions and front-end errors all over the place across what appears to be all services, though Gmail seems to have bounced back up. Google's service disruption is about to bring Twitter's service to its knees as people complain and try to figure out what's going on. Blair Trosper Updraft Networks & The North Texas GigaPOP From jna at retina.net Wed Oct 31 22:01:05 2012 From: jna at retina.net (John Adams) Date: Wed, 31 Oct 2012 15:01:05 -0700 Subject: Google burp In-Reply-To: References: Message-ID: Hey now, we're doing fine over here at Twitter. :P -j On Wed, Oct 31, 2012 at 2:55 PM, Blair Trosper < blair.trosper at updraftnetworks.com> wrote: > I guess I'll be the one to ask...what's going on over at Google? Service > interruptions and front-end errors all over the place across what appears > to be all services, though Gmail seems to have bounced back up. Google's > service disruption is about to bring Twitter's service to its knees as > people complain and try to figure out what's going on. > > Blair Trosper > Updraft Networks & The North Texas GigaPOP > From blair.trosper at updraftnetworks.com Wed Oct 31 22:03:48 2012 From: blair.trosper at updraftnetworks.com (Blair Trosper) Date: Wed, 31 Oct 2012 17:03:48 -0500 Subject: Google burp In-Reply-To: References: Message-ID: I was editorializing the quantity of tweets about the Google outage more so than the quality of service of Twitter. :) Apologies. On Wed, Oct 31, 2012 at 5:01 PM, John Adams wrote: > Hey now, we're doing fine over here at Twitter. :P > > -j > > > On Wed, Oct 31, 2012 at 2:55 PM, Blair Trosper < > blair.trosper at updraftnetworks.com> wrote: > >> I guess I'll be the one to ask...what's going on over at Google? Service >> interruptions and front-end errors all over the place across what appears >> to be all services, though Gmail seems to have bounced back up. Google's >> service disruption is about to bring Twitter's service to its knees as >> people complain and try to figure out what's going on. >> >> Blair Trosper >> Updraft Networks & The North Texas GigaPOP >> > > From djahandarie at gmail.com Wed Oct 31 22:04:41 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 31 Oct 2012 18:04:41 -0400 Subject: Google burp In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 5:55 PM, Blair Trosper wrote: > I guess I'll be the one to ask...what's going on over at Google? Service > interruptions and front-end errors all over the place across what appears > to be all services, though Gmail seems to have bounced back up. Google's It's just the annual exercise to remind people how reliant they are on a single company/infrastructure. -- Darius Jahandarie From maxsec at gmail.com Wed Oct 31 22:06:32 2012 From: maxsec at gmail.com (Martin Hepworth) Date: Wed, 31 Oct 2012 22:06:32 +0000 Subject: Google burp In-Reply-To: References: Message-ID: Same in uk as well just got service back On Wednesday, 31 October 2012, Blair Trosper wrote: > I was editorializing the quantity of tweets about the Google outage more so > than the quality of service of Twitter. :) Apologies. > > On Wed, Oct 31, 2012 at 5:01 PM, John Adams > > wrote: > > > Hey now, we're doing fine over here at Twitter. :P > > > > -j > > > > > > On Wed, Oct 31, 2012 at 2:55 PM, Blair Trosper < > > blair.trosper at updraftnetworks.com > wrote: > > > >> I guess I'll be the one to ask...what's going on over at Google? > Service > >> interruptions and front-end errors all over the place across what > appears > >> to be all services, though Gmail seems to have bounced back up. > Google's > >> service disruption is about to bring Twitter's service to its knees as > >> people complain and try to figure out what's going on. > >> > >> Blair Trosper > >> Updraft Networks & The North Texas GigaPOP > >> > > > > > -- -- Martin Hepworth, CISSP Oxford, UK From michael at rancid.berkeley.edu Wed Oct 31 22:06:33 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 31 Oct 2012 15:06:33 -0700 Subject: Google burp In-Reply-To: References: Message-ID: <5091A0E9.30801@rancid.berkeley.edu> On 10/31/12 2:55 PM, Blair Trosper wrote: > I guess I'll be the one to ask...what's going on over at Google? Service > interruptions and front-end errors all over the place across what appears > to be all services, though Gmail seems to have bounced back up. Google's > service disruption is about to bring Twitter's service to its knees as > people complain and try to figure out what's going on. > > Blair Trosper > Updraft Networks & The North Texas GigaPOP > It's back working for me (after just a few minutes of brokenness), but I have to say I really loved the "out of order" splash page I got when my calendar went down: "Sorry, there seems to be a problem. The service you're looking for is temporarily unavailable. Please try again in a few hours. Thanks for your patience." Ahem, a few *hours*? From stealth702 at gmail.com Wed Oct 31 22:35:19 2012 From: stealth702 at gmail.com (Jeremy) Date: Wed, 31 Oct 2012 22:35:19 +0000 Subject: Google burp In-Reply-To: <5091A0E9.30801@rancid.berkeley.edu> References: <5091A0E9.30801@rancid.berkeley.edu> Message-ID: I had my service go down and come back and when it came back i have the new reply/compose features of the new gmail system http://techcrunch.com/2012/10/30/googles-gmail-launches-new-compose-email-view-and-reply-experience-that-will-save-you-time/ It wasn't there before On Wed, Oct 31, 2012 at 10:06 PM, Michael Sinatra wrote: > On 10/31/12 2:55 PM, Blair Trosper wrote: >> I guess I'll be the one to ask...what's going on over at Google? Service >> interruptions and front-end errors all over the place across what appears >> to be all services, though Gmail seems to have bounced back up. Google's >> service disruption is about to bring Twitter's service to its knees as >> people complain and try to figure out what's going on. >> >> Blair Trosper >> Updraft Networks & The North Texas GigaPOP >> > > It's back working for me (after just a few minutes of brokenness), but I > have to say I really loved the "out of order" splash page I got when my > calendar went down: > > "Sorry, there seems to be a problem. The service you're looking for is > temporarily unavailable. Please try again in a few hours. Thanks for > your patience." > > Ahem, a few *hours*? > > > From ag4ve.us at gmail.com Wed Oct 31 22:49:24 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 31 Oct 2012 22:49:24 +0000 Subject: Google burp In-Reply-To: References: <5091A0E9.30801@rancid.berkeley.edu> Message-ID: On Wed, Oct 31, 2012 at 10:35 PM, Jeremy wrote: > I had my service go down and come back and when it came back i have > the new reply/compose features of the new gmail system > > http://techcrunch.com/2012/10/30/googles-gmail-launches-new-compose-email-view-and-reply-experience-that-will-save-you-time/ > yeah, be careful with their new compose feature. i'm used to vim, so i hit esc half way through an email which generally does nothing. however, with this "new" feature, it closed the email. then it took it longer to appear in drafts than it did to compose a new email. so, now i've disabled it. i hope they don't force the issue until they give me vim key bindings in my email editor :) From cmadams at hiwaay.net Wed Oct 31 23:43:44 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 31 Oct 2012 18:43:44 -0500 Subject: Google burp In-Reply-To: References: <5091A0E9.30801@rancid.berkeley.edu> Message-ID: <20121031234344.GF19113@hiwaay.net> Once upon a time, shawn wilson said: > yeah, be careful with their new compose feature. i'm used to vim, so i > hit esc half way through an email which generally does nothing. > however, with this "new" feature, it closed the email. then it took it > longer to appear in drafts than it did to compose a new email. so, now > i've disabled it. i hope they don't force the issue until they give me > vim key bindings in my email editor :) Have you tried the Firefox add-on that can turn input boxes into vi mode? Does that work with Gmail? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.